G.T.A.2 Map Editor

[User137]

SilverWarior has good tips. I would do 2) to hold 256x256 colored vertex array for the pixels. Render it into texture as a 256x256 grid, that's what framebuffer demo in nx is about. It might be a little complicated demo though. You can optimize it by having a boolean variable "minimapChanged". Every time you draw to tilemap it is set True. Then every half second check if it's True. If it is, then set it False and generate the minimap texture again. For actual map drawing you're only drawing 1 quad per frame. Change texture coordinates based on where the camera is.

edit: You can draw the whole map as is into framebuffer, if you want to make it simple and memory efficient. It will just take longer time to render. But then you can zoom the minimap with texture detail, depending on the texture resolution used on minimap. 512x512 would still only show you 2x2 area of 1 tile, but it's much more detail than 1 pixel.

And, what it means to draw into texture... Think if it as drawing the whole map onto your screen in ortho mode. Scaled exactly in area of texture resolution 512x512 if that's what it is. You should definitely test by rendering it on screen first to see that the boundaries are right, and then switch to render it to texture.

[SilverWarior]

I would do 2) to hold 256x256 colored vertex array for the pixels.

Why bothering with veticles if you can simply do this with normal pixels. You can always stretch that texture to fit the desired size if needed.

You can optimize it by having a boolean variable "minimapChanged". Every time you draw to tilemap it is set True. Then every half second check if it's True. If it is, then set it False and generate the minimap texture again.

Why not change minimap texture as soon as you do any change to the map? Since you are usually changing one tile at a time this means that you only need to change one pixel or smal portion of your map if it is generated from map-specific mini sprites. I mean there is absolutely no need to redraw the whole map but only change the relevant part of it.

As for your suggested approach that is more suitable to be used inside a game where map changes are more rapid (unit movments etc.) but in map editor there is no use of that.

[User137]

Oh you mean altering the texture data directly. Well, you might have glTexSubImage2D(), but i don't have experience of that.

With normal methods you aren't able to change just 1 pixel, but render the whole minimap. Besides when you're editing the map you are watching the main screen where cursor is. By the time you move your eyes to minimap, with 500ms interval it would already be updated. And in the playing mode the minimap is normally not changing. Or if it, you can have an additional transparent map texture for dynamic objects.

I just uploaded new nxPascal to SVN, with change to framebuffer demo. I had previously left it with window size locked to framebuffer size 512x512, but now it works with any window size, to emphasize the fact that screen buffer size has nothing to do with texture size.

[SilverWarior]

Oh you mean altering the texture data directly. Well, you might have glTexSubImage2D(), but i don't have experience of that.

To be honest I also don't have much expirience with this, especially on OpenGL level. I did try once achiving this using Aphyre Sphinx TAsphyreLockableTexture which provides you with acces to each pictures pixel if needed but I don't know which OpenGL cal the Asphyre Sphinx makes for this to work.
Another way would be to simply use ordinary TBitmap to store minimaps data and then render this butmap on screen (many graphical engines alows doing this).

Besides when you're editing the map you are watching the main screen where cursor is. By the time you move your eyes to minimap, with 500ms interval it would already be updated.

@User137 if you need 500ms to change your eyes focus from one point on the monitor to another you gotta be getting realy old
Plese don't be ofended by my previous statement but 500ms is enough for average human not ony change the focus of his eyes from one point to another but to even turn his head for about 30 degres.
Also you have to asume that user decides to change his eyes focus at the same time he decides to do a mouse click. And since it takes a bit of time from the pint when you decide to do mouse click and actually do it your eyes could already be on the half way to destination focus point.

And in the playing mode the minimap is normally not changing. Or if it, you can have an additional transparent map texture for dynamic objects.

Yes using multiple layers for ingame minimaps is quite often especially if the minimap background is made from series of so caled minisprites.

[User137]

if you need 500ms to change your eyes focus from one point on the monitor to another you gotta be getting realy old
Plese don't be ofended by my previous statement but 500ms is enough for average human not ony change the focus of his eyes from one point to another but to even turn his head for about 30 degres.
Also you have to asume that user decides to change his eyes focus at the same time he decides to do a mouse click. And since it takes a bit of time from the pint when you decide to do mouse click and actually do it your eyes could already be on the half way to destination focus point..

That was just an example Main part is still that you shouldn't do the texture-memory update in the event of mousemove, but at the beginning of render function, all changes at once, and only if there are changes. 500ms is just an example, might aswell be 100ms. Take a look at Starcraft 2 editor for example. While you are painting terrain and moving mouse rapidly, no changes to minimap are done. But if cursor is on 1 spot for about 500ms or release mousebutton, then update happens. These are just optimization tricks for when they are needed. Like if your minimap means actual polygon rendering of the whole world, with light environment and everything.

[hwnd]

Working few days already on this thing. Today i messed again with selection boxes and noticed that Delphi 7 either has bug or it just has to be that way..

Here is snippet from drawing of block selectors:

                glTranslatef(

                  Iff(frmMain.XPositive,(selcount2+selx), (-selcount2+selx))-0.5, // 1

                  Iff(frmMain.ZPositive,(selcount+selZ), (-selcount+selZ))-0.5,  // 2

                  Iff(frmMain.YPositive,(selcount1+selY), (-selcount1+selY))-0.5, // 3
                  

                );

You see comments there 1..3 at the end of the lines. So at the 3 comment you see the comma?
Delphi 7 compiles without any error, which is strange, but if i put anything after the comma, it will give error, "too many parameters".


My D7 is very slow for some reason and hangs when compiling, then wakes up and runs my project, maybe i will have to format my laptop again.
So i decided to look how fast the compiling is done in XE.
I must say that even heavy XE on my old poor laptop here is faster than D7 IDE.
Dunno how that could be.

So i opened this project in XE and this immediately generated error that there is too many parameters, he saw the comma there.

So what is this? Bug or hidden feature? D7 just ignores commas, if there is no actual values after such "final" commas?

I didnt notice that comma was there, its a XE which pointed me to that.

[SilverWarior]

My D7 is very slow for some reason and hangs when compiling, then wakes up and runs my project, maybe i will have to format my laptop again.

Maybe you wanna check your antivirus software. If you have residental protection on and in depth heuristic scanning enabled and your final exe contains quite some resources in it, it could take a while before antivirus finish scanning it (it actually extracts the resources from your exe and checks them seperately).

It is posible that your are slowly running out of free disk space on your system partition whoich could lead to files which are saved in Temp folder to be higly fragmented which could lead to slowdowns. D
efragmenting your hard drive might improve this. Also as a general note I recomend having athleast 1GB of fre HDD space on your primary partition or in case of dynamic alocatable page file size even more free space. I ususlly have fixed size of page file set to 150% size of my RAM.
Having fixed sized page file could mean great difference on Windows XP as the pagefile tends to become realy fragmented othervise.
Another thing that might lead to such problems is partially damaged sector on your hard drive which is causing slowdowns.