OpenGl and selective drawing

[code_glitch]

Now, this is one I may or may not have the answer to but can't get it right. I have a large gl texture which loads an image. From this, I calculate the the positions of sprites/tiles on it. That all seems to work no problem. The problem is when I need to draw a part of that image in opengl.

I remember SDL has a Sdl_Rect you can use with sdl_blitsurface but I am avoiding that for major performance issues. I think it has something to do with the:


glTexCoord2i( VxR[1], VyR[2] );
(ignore variables, directly from source) and I have to adjust the first decimal as a percentage (ie. 0.4758532875328947238947238947 yada yada) but how accurate is this? Since my code tries to support 'tilesets' of up to 90,000 tiles... (In case someone runs out although I doubt it).

Or if the above is all wrong how would you go about doing this??? Really lost again :D

Edit: and everything I try says it has to be a longing - that cannot support the decimal point.???
Edit2: ah baka-mistake - use gltexcoord2f!!!!! that solves the integer issue but how does it all work??? waaaa.

[Andru]

but how accurate is this?
Accurate enough to set texture coordinates with pixel precision :)


that solves the integer issue but how does it all work
Instead of integer values you must use values like 1 / ImageWidth * X and 1 / ImageHeight * Y.


yada yada

baka-mistake
^__^

[code_glitch]

oh yes - baka mistake. Still testing it out. I have to admit: tileset support is a nice thing to have - that way I don't have to re-write a special one for each program I make. :)

[code_glitch]

Finally isolated the problem - selective drawing works 100% fine. Its the tileset management that is messing up haha. And its a baka-implementation to blame. Nice long fix - or a rewrite. I think both are required here. Its hella-fast though.

edit: but I just realized it messes up with scaling... its another bug to fix. hooray.
edit2: ignore the last baka-edit about the baka-bug. I found it: standard (and handy opengl behaviour) DUUUUH! if you take a 300x300 texture and draw it 1000x1000 it 'tiles' itself multiple times to fill! ;)

[code_glitch]

All fixed now. Engine seems to run at 600tiles/sec if you update to screen each time. If you dont its somewhere over 55,000 tiles/second on my 1.2ghz su4100 at 45% background cpu usage. Not bad if I may say so myself. Here is a demo program of it all:



program TileSetTest;

uses
Prometheus_Vid;

var
TS: TileSet;
cx: Int64;
cy: Int64;
c: Int64;

begin
PrometheusVid_Start();
CreateWindow(1280, 600, 32);
UpdateWindow();


TS.LoadFromImageFile('TileData.png');
TS.SetOffset(2,3);
TS.SetSpacing(1,1);
TS.SetTileSize(16,16);
TS.SetTileTable(140,140);
Ts.SetTiles(10000);
Ts.Update();

cx := 0;
cy := 1;
c := 0;
repeat
cx := cx + 1;
c := c + 1;
Ts.DrawTile((cx - 1) * 16, (cy - 1) * 16, c);
if cx >= Ts.TilesPerRow then
begin
cx := 0;
cy := cy + 1;
end;
until cy > 500;
UpdateCanvas();
readln();
end.
The SetTiles() is not actually required but I put it in as a fallback if something like TS.Update fails entirely.

PS: This uses <~20mb of ram to load a alpha 2739x2264 png tilesheet and draw it along with all other prometheus crap.

[User137]

There is 1 other "feature" that is caused by linear filtering... Imagine your tilemap texture like this:

RRRRWWWWRRRR
RRRRWWWWRRRR
RRRRWWWWRRRR
RRRRWWWWRRRR
RRRRRRRRRRRR
RRRRRRRRRRRR
RRRRRRRRRRRR
RRRRRRRRRRRR
...where R is red pixel and W is white, and pattern size is 4x4. Now if you draw pattern 1 which is full W, it will show red borders to it.

This can be fixed by for example leaving a empty transparent black line between each tiles.
Or skipping half pixel length from the texture coordinates at borders.

Oh, and 2739x2264 will not most likely work on most graphics cards, my own to name 1 (Radeon HD 5770). Texture width and height must be power of 2, for example 512 x 1024, it doesn't have to be square.

[code_glitch]

Don't worry: assuming the Update() procedure is callibrated correctly that problem is (theoretically) impossible. I've already tried it out and it works a treat ;). And since the drawing is handled by the Image.Draw procedure - which I spent a fair amount of time on to avoid the even problem - I have managed to work with odd-number pixels as dimensions and have detected no problems. After all - prometheus is here to make programming easier and faster; not easier but longer because of glitches and weird bugs XD