Log In  

Hello.

Something good game programming languages have had for a long time is called "Virtual resolution."

For instance with Pico-8 you could have this sprite:

[8x8]

And then this code:

cls()
setvirtualresolution(16,16)
for i=0,3 do
  for j=0,3 do
    spr(1,j,i)
  end
end

And you would get a perfect set of blocks 4x4 at 8x8-pixels each. No need to multiply by 8 each time.

[32x32]

Fractions are also possible, if for instance you wanted to plot between one of the 16x16 blocks, you would use .5

For instance:

cls()
t="amazing grace"
setvirtualresolution(16,16)
print(t,8-#t*.5,1)

Which would show the text centered and on the 8th vertical pixel, even if the text had an odd number or even number of characters, by calculating 64 minus the length of the text times decimal 5, you would get the correct results each time.

You could even do this with 4-arguments, setvirtualresolution(-1,1,1,-1) so zero would be the center of the screen and -1 and +1 being the far edges of the screen.

How about it, @zep ?

Guys, what do you think ?

P#119331 2022-10-19 19:44 ( Edited 2022-10-19 20:05)

we have modes to reduce width or height or both to 64px, so I don’t see more options being added.

P#119342 2022-10-19 22:29

Hi @merwok. No, this is a common thing to be able to graph where the center is 0,0. Reducing the resolution to 64x64 does not actually change any commands.

Meaning changing the visual resolution does not actually affect any commands at all. You just visually draw outside the 64x64 area and the rest of your program does not know the difference.

It still thinks you are running at 128x128 although cropping the top-left-hand corner and viewing them double-pixels, that is all.

I still would like, virtualresolution() to be enabled that mathematically acts on the coordinates in commands such as spr() sspr() print() line() rect() circ() etc.

P#119343 2022-10-19 22:33 ( Edited 2022-10-20 00:08)

I hadn't heard of this concept before. I just tried googling it and all the results I got were about features on graphics cards rather than game engines, which kinda makes sense given that on a modern game-engine (rather than retro one) you could just off-screen render some stuff and then blit it where ever you intended it to be at any resolution. Is there some other term for this that's more common?

As for the actual feature, wouldn't it make more sense to make this an extension of the existing camera() command? In that case you'd be defining the camera as a viewing rect rather than a viewing position.

P#119353 2022-10-20 01:06

Hi @kimiyoribaka.

It was something I learned back in college I believe.

https://www.varsitytutors.com/hotmath/hotmath_help/topics/graphing-scale-and-origin

Certainly it would be useful for graphs and charts. As for me, I make use of it in Blitz thus:

Function SetVirtualResolution : Int
(  width  : Float  
 height  : Float  
)  

Set virtual graphics resolution 

SetResolution allows you to set a 'virtual' resolution independent of the graphics resolution.
This allows you to design an application to work at a fixed resolution, say 640 by 480,
and run it at any graphics resolution. 

In this I can create a game that works in a resolution of 640x480 but then later I can rescale the physical window to 800x600 or 960x720 using:

graphics 960,720
setvirtualresolution 640,480

and nothing is lost, it is all rescaled perfectly to the virtual resolution of 640,480.

Personally in Pico-8 I would like to scale the screen to 16x16 so when I plot 8x8 pixel tiles I do not need to multiply by 8 nor divide by 8 later.

P#119356 2022-10-20 02:01 ( Edited 2022-10-20 17:00)

[Please log in to post a comment]