Determining Vram usage question.

BlitzMax Forums/BlitzMax Beginners Area/Determining Vram usage question.

Galdy(Posted 2013) [#1]
I found this from an old post on the forum here. -

"Images are stored *uncompressed* in video memory, taking 4 bytes for each pixel (32 bit: 24 bits for the color, and 8 bits for alpha info)
- memory allocated rounded *up* to the nearest power-of-two size.
This means that an 800x600 pixel JPEG file that's 50KB on disk, all of a sudden takes up 1024 x 1024 x 4 = 4 MB of video RAM."

I have a door animation for my fps dungeon crawl, like the old dungeon master game, that is 1573 x 1080 pixels per frame. This would then be rounded up to 2048x2048 x 4 bytes x 60 Frames = 16.7 MB per frame x 60 frames = 1002+ MB! So that's over 1GB of Vram just for my door animation!? lol. I must be going at this all wrong then. The static assets don't take to much vram, but animations at this rate will never work it seems. I probably need to consider Vcards down to 512 mb, but this is a prob for even high end. Anyway, where am i going wrong or not understanding here?


Gabriel(Posted 2013) [#2]
If you're making a first person shooter, then it's 3D, isn't it? In which case you shouldn't be animating textures for anything larger than spot particle effects. You should be animating vertices - or whatever passes for vertices if you're raycasting or some other 2D/3D hybrid.

I haven't done the math, but your VRAM calculations seem right.


Galdy(Posted 2013) [#3]
Sorry, I forgot to mention im doing it in 2d. I render scenes to pngs and cut out the assets for display. No problem as far placing static images for walls and items in the dungeon. Animations are another issue. As stated.


Gabriel(Posted 2013) [#4]
Yep, well that's not going to work, as you've already determined. You're going to have a find a way of faking it. Rotating the image might work if you can work in the third dimension, or skewing them might be effective if you cannot. To be honest, a screenshot of one of your scenes would probably make it easier to visualize a solution.

I'm imagining something like this:



For something like that, where the perspective center is above the mid point of the screen, you would have to skew unevenly, top and bottom - if you see what I mean.

EDIT: Added an image to illustrate my (probably poor) description.



I've had to skew the right hand door more on the top than on the bottom to make the perspective look right. I'm not an artist, so the perspective is probably still wrong, but hopefully you see what I'm getting at.


xlsior(Posted 2013) [#5]
one 'obvious' solution would be to dramatically cut down the # of frames: Do you really need a different image each 1/60th of a second while the door is opening?


Galdy(Posted 2013) [#6]
Well I guess I just needed confirmation of what I already kind of figured out. Rotate is an option since it is a rolling stone door. Just wont look as good. Its probably my only option really. Gabriel, Yes, something like that. I'm at 30fps. Two seconds worth.


Galdy(Posted 2013) [#7]



Calibrator(Posted 2013) [#8]
Definitely rotate it.

You need to scale the door anyway (I assume that you support more resolutions than 1080p, don't you?) and when you draw it you can also rotate it.

Are all doors of the same kind?


Derron(Posted 2013) [#9]
Slice your sprites

1573x1080
can be sliced into:
1024x1024 + rest

rest is 1573x56 -> 2048x64
you can even split that too.

As a helper just create a "BigImage"-Class which does everything needed for you automatically.


Something like this should do it:


But... this adds more drawcalls (and in this implementation also "switches" between bound textures).


As some already covered a bit: for huge resolutions better use "3d in 2d". So you have a polygon which you manipulate instead of animated sprites.

Exception are background assets - but those are mostly not 60fps animated.


bye
Ron


xlsior(Posted 2013) [#10]
Slice your sprites


That would dramatically complicate him rotating them, though.


Derron(Posted 2013) [#11]
It only complicates things if you have your handle inside the images borders. As soon as all share the same handle (eg. the center) position. Rotation is just a matter of "google-able" math formulas.


bye
Ron


John G(Posted 2013) [#12]
Side question: How do you force smooth 30 fps vs. 60 fps? Thanks.


Derron(Posted 2013) [#13]
Use DeltaTiming (for physical updates ... movement etc) plus Tweening when Drawing them.

So you update your "position" according to a fraction of a second used for this update. Before setting the current position, a backup position has to get fileld.

Your drawing functions/methods have access to a "tweenValue" (how position from 0.0-1.0 marking how many time was left until the next draw-call/frame). Then just tween between the positions.

So you can have less update (physic) calls then needed for "animating" while the tweenValue takes care of smooth displayed animations.


bye
Ron


Galdy(Posted 2013) [#14]
Thanks for the input guys. Very helpful. Another question. Now that i can't use my door animations, I lose my light level information based on distance away from the door. So what's a good way to darken the image a touch? I would need to darken it down to 4 different levels since it can be seen from up 5 grid squares away. Something like Alpha blending a square over the image? I haven't ever used the blend functions before.


xlsior(Posted 2013) [#15]
Something like Alpha blending a square over the image?


That's one possibility. Alternatively:

To draw an image full brightness:

setcolor 255,255,255
drawimage


to draw a half-brightness version:
setcolor 127,127,127
drawimage

..or any combination and intensity of colors.

Of course, make sure to change back to setcolor 255,255,255 afterwards so your other drawing operations aren't affected.


Galdy(Posted 2013) [#16]
Ok. I'll try that. That would be less memory usage.


Calibrator(Posted 2013) [#17]
By the way: How do you lighten the walls on either side of the door? Do they always have the same brightness? (I assume that you use different images depending on the distance)

Edit:
By the way, you may really want to read up on ALPHABLEND, even if you don't use it to overlay lightmaps as it is dead easy to create partly invisible enemies (for example ghosts) or cloaked characters with it.
You basically only need two instructions:

SetBlend(ALPHABLEND) 'set blend mode
SetAlpha (x) 'x = 0.0 to 1.0, whereas 0.0 means completely transparent and 1.0 means completely solid

Most standard drawing instructions work with that.

The same caveat applies here, too, though:
Reset the alpha for drawing instructions that draw solid stuff (like walls)!
SetAlpha (1.0)


Galdy(Posted 2013) [#18]
xlsior yep. That works great.

Calibrator. You are right. Different images swapped out for walls lit with a torch. For the door I just had to settle on one large image that with one light setting on it and scale and rotate. Then setcolor as required for distance. Not as good as the perspective and light information that would have been in the animation, but that was too much of a mem hog.


Kryzon(Posted 2013) [#19]
This reminds me of Myst, the first game. The static screens were high resolution.
The animated parts were low resolution; They were movie files under the QuickTime format.
You could notice the difference - when a static screen would transition to the low-resolution movie and start playing - but you would take it as part of the game, it didn't really matter.

Since you seem to be using pre-rendered graphics, rotating that wheel door manually should look less cinematic.
You could use a pre-rendered movie of it. There's an OGV video player from Brucey over here:
- http://code.google.com/p/maxmods/source/browse/trunk/theoraplayer.mod/
- http://code.google.com/p/maxmods/source/browse/trunk/theoraplayeropenal.mod/
- http://code.google.com/p/maxmods/source/browse/trunk/theoraplayerbass.mod/

You need an SVN client to download those "theoraplayer" folders. Then place them in BlitzMax\mod\ and compile them as instructed in the threads in Brucey's forum:
- http://blitzbasic.com/Community/posts.php?topic=95220#1095313
- http://www.blitzbasic.com/Community/posts.php?topic=101593#1207346

Alternatively, you could stream chunks of the animation from the HD using a child thread, sending data to the main thread using events and event-hooks. This should allow you to keep the original resolution.


Calibrator(Posted 2013) [#20]
Video streaming is an interesting idea and I agree that it can look the best if you use lots of pre-rendered animation frames - and you obviously wouldn't hog system memory as the animation is streamed in from disk.

You can also easily use small things to increase atmosphere like debris and dust particles falling down from the door and ceiling gap where the door slides in. The dust doesn't need to be collected on the ground, the movement of it falling down suffices.
You can do this with traditional image animation on top of a rotating door, too, but you would have to render that on-the-fly.

On the other hand you would still need to pre-render all animations and they would still consume disk space - especially, if you use torches on either side of the door (or both) and different door designs.

The Myst games were early CD games as they couldn't get the same result with floppy disks. If you distribute your game as downloads we possibly talk about a couple of gigabytes, at least if you use the videoplayer for other animations, too...

In your shoes I'd still first test the door animation with a rotating image but applying a lightmap image over it, that is not single-colored but has a brightness fall-off from the left to right (if the torch is on the left wall - or mirrored if the torch is on the right wall). The lightmap of course does not rotate as the torch stays in the same place ;-)...

Testing this would only require one door image and one lightmap - see if you are happy with the results and then do what your heart tells you.


xlsior(Posted 2013) [#21]
In your shoes I'd still first test the door animation with a rotating image but applying a lightmap image over it, that is not single-colored but has a brightness fall-off from the left to right (if the torch is on the left wall - or mirrored if the torch is on the right wall). The lightmap of course does not rotate as the torch stays in the same place ;-)...


And you can do that by using a Alphablended mask, with the 'lit' side fully transparent, and the unlit side progressively darker


Kryzon(Posted 2013) [#22]
You can also easily use small things to increase atmosphere like debris and dust particles falling down from the door and ceiling gap where the door slides in. The dust doesn't need to be collected on the ground, the movement of it falling down suffices.
You can do this with traditional image animation on top of a rotating door, too, but you would have to render that on-the-fly.

That is an interesting way to camouflage the procedural animations. A lot of special effects, fog etc. that composite into a rich scene.


Galdy(Posted 2013) [#23]
Those are some great ideas. I'll need to try to make the environment a little less "sterile" and doing some environmental effects would help with that. The other daunting task ahead yet is rendering some animation sequences for enemies lurking around in the dungeon. It will take some frames to do that, but I can scale a base set hopefully that will look good enough and not be to much memory consumption. Long ,long way from that though. Still banging away at assets.