G.T.A.2 Map Editor

[hwnd]

The brain.wireos sty reader is the one i use because he wrote this for me. And the code is so fast.

And thanks to this im able to render these sprites and stuff. But yes for emergency lights on cars etc, its a bit complicated but nothing impossible i guess. Atm i just want to render sprites/game objects on map.

But npot textures scared me. But now it seems OK.

Btw, just for the info, from the STY docs:

"5.1 Sprite Graphics Data
Sprites are stored as uncompressed 256-colour graphics upto 32 pages of 64K each. Each page is 256x256 pixels. The maximum size of a sprite is 128x64 and the minimum is 2x2. The width and height can have any value inbetween as long it is an even number."

[User137]

I know you are still using bit of your own texture loading, but i'll still give short example how nxPascal would do NPOT. You can download Delphi source and exe here. I made it as simple as possible but based on the game template:
https://docs.google.com/file/d/0B7FI...NlYWRvLW8/edit

There is no scaling of any kind, demo loads in 119x53 texture with 12 patterns in 6x2 grid. There is SkipWidth and Height of 1 because i drew it quickly with a green 1 pixel wide grid, which i had to take off because bi-linear rendering makes the grid show when drawn.

To summarize key points:

n:=tex.AddTexture('anim', GetPath('textures\anim.png'), true);
tex.SetPattern(n, 19, 26, 1, 1);
...
pattern:=(pattern+1) mod 12;
nx.DrawRotate((i mod 30)*15.0+20, (i div 30)*15.0+20, pattern, 0, 0.5, 0.5);
// I drew 1000 of these patterns, 30 per row, each centered around coords 0.5, 0.5 of the pattern, that's exactly in the middle.

[phibermon]

well filtering a texture atlas is always going to give you issues like you describe, keeping a transparent border around sub-textures is the usual generic solution, GL_CLAMP_TO_EDGE won't help you as you're not necessarily addressing the texture up to it's edge for all sub-images.

Caveats you must accept for the performance gains of a texture atlas.

I'm working in OpenGL 4.x currently and I don't support anything less than 3. I did that specifically because I didn't have to jump through all the hoops. I'm guaranteed to have NPOT support, guaranteed to have uniform buffers, tessellation stages on 4.x hardware blah blah blah

it's so much less of a headache than GL1.x GL2.x, GLES etc

And it's only a matter of time before GL2.x is about as common as Glide (3DFX) plus the next itteration of GLES will be in the GL3.x/4.x style.

If you're working on projects with epic timescales, you've got to plan 3/4 years ahead. If you don't then you end up like GLScene with almost no ability to switch to the current versions (GL3 is old now) except a significant re-write of many parts.

I mean look at all those epic game titles from the 90s, games coming out in 1997/98 that ran in DOS!

You've got to think ahead, I'd advise anybody to throw GL1.x and 2.X out of the window immediately (pun intended) and work in a GL3 core profile at the very least. Doesn't matter if your card doesn't support it, that's what Mesa is for. And if you miss immediate mode functions for debugging purpouses, use a delphi/lazarus form with your window to display stuff or just re-implement immediate mode functionality on top of VBOs and shaders, I did that and never looked back.

[User137]

I'm working in OpenGL 4.x currently and I don't support anything less than 3. I did that specifically because I didn't have to jump through all the hoops. I'm guaranteed to have NPOT support, guaranteed to have uniform buffers, tessellation stages on 4.x hardware blah blah blah

it's so much less of a headache than GL1.x GL2.x, GLES etc...

I have plans for that, it's just lots of work... I already rewrote the shader classes 2 weeks ago so the "concrete basing" is already set tight Building the renderer and all the shaders won't be easy though. Basically the 2D drawing code from programmers part will hardly change at all. Instead of nx.DrawRotate(), you'll just propably get nx.renderer.DrawRotate() with same parameters. The plan is to have polygon queue which adds and adds stuff, and then draw all of them at once. On change of texture, polygon mode (triangle/quad), or shader program change it will render the queue and start over again. That stuff should be invisible for the programmer. I would also be able to support uniform light arrays for example, in theory at least. Almost can't wait to get writing the shaders, just that true game programmer is also a gamer himself that is the major issue