Proposed DrawImage/LoadAnimImage Module Change

BlitzMax Forums/BlitzMax Programming/Proposed DrawImage/LoadAnimImage Module Change

flying willy(Posted 2004) [#1]
Proposal
-----------


Change LoadAnimImage so that it accepts an optional flag to "keep images within same texture".

DrawImage will then not change texture at render when different frames are drawn, if the previous frame was of the same texture.

reason for proposal
-------------------------


Currently LoadAnimImage forces the split into seperate textures, and with animated aliens for example, leads to progressive slowdowns as demonstrated on this thread: http://www.blitzbasic.com/Community/posts.php?topic=41644

The changes will enable tilemap displays, as well as real game situations to be rendered much, much faster and will benefit lower end hardware.

Unneccesary texture switching is avoided currently in blitzmax while drawing single images, but not with LoadAnimImage.

In a real game situation this has led to progressive slowdowns, not currently demonstrated in the samples.


Please post your own comments and any thoughts, they are very welcome. I am personally hoping BRL will take these issues on board and make the relevent optimisations.


flying willy(Posted 2004) [#2]
I have also tested the NEW code from Michael, on the thread linked to in the above post, and while grouped is still faster on my card, it is inconclusive. I think we need to bear in mind possible bottlenecks if Blitzmax is to be the best it can be.


skn3(Posted 2004) [#3]
Well seeing as we have access to the functions themselves it makes sense that it doesn't have to be BRL that does this. Plus I think it is really a bit early to be creating a topic like this. It isnt even officialy out on pc yet. X)


Michael Reitzenstein(Posted 2004) [#4]
It doesn't have to be BRL written, but it DOES have to go in the official modules.


flying willy(Posted 2004) [#5]
Thank you for your thoughts. The jury still seems out on the effectiveness of the changes so we will have to wait and see!

An official murmour from Mark and Simon would be nice as well. I understand that you are busy, but your input is invaluable.


skn3(Posted 2004) [#6]
Yeah it def needs to be a part of the official mod. That was the idea (i think) to release the mod source so the public can improve on it and hopefully submit it for addition.


ImaginaryHuman(Posted 2004) [#7]
You can always bypass the Max2D routines which are basically just higher-level helper functions, and write your own direct OpenGL programs - incorporate those extra wide or tall textures with anim frames in them, etc. (although it would be nice if this kind of thing was part of the max2d routines)


ImaginaryHuman(Posted 2004) [#8]
Does using a single texture for all the frames simply entail setting up the texture coordinates differently for each frame you want to be rendered?


jhague(Posted 2005) [#9]
Here's an alternate proposal:

Add a new image state command called SetRect (or possibly SetSubimage): SetRect X,Y,Width,Height. This limits the part of the source image that is drawn, so you can essentially choose parts of a larger image. SetHandle is computed relative to this rectangle, so you can have an independent hotspot for each subimage.

The SetRect command could be used to implement animated images without breaking them up into separate textures. It could also be used to implement general image packing.

Or, as a second alternative, have a DrawSubImage command that also takes a rectangle as four parameters.

Thanks for listening!