nxPascal

[User137]

1) Why do you need to reinitialize rendering context other way than usual, application start? Notice that you will lose all loaded textures when doing so. If TGraphicalGame was freed properly, it will recreate them in constructor as should. For something like using multiple "rendering windows", this sort of behavior is not needed at least. OpenGL can quickly switch between rendering contexts. That's again going to territory i haven't tested, and implementation differs on Delphi and Lazarus.

2) You will be ok without the onPaint. In the constructor of TGraphicalGame, it might be calling CenterMouse() if you want to make for example FPS game, or space simulator like that picking demo. onFormCreate does not know much about window size and position yet, so it would give mouse a random "warp" effect at start... That's why TGraphicalGame should only be created once the window exists and is visible.
For example, if form1.Position is poScreenCenter, it is only made effective at onPaint the earliest. onFormCreate and even onShow still don't know the real values.

[hwnd]

I don't care about reloading textures, i work with tiles of 64x64 and i have my own cache system that loads and deletes textures from memory, if they are needed, they are always automatically loaded. User wouldn't even notice that textures were removed or reloaded.

I don't need to init OpenGL immediately in FormCreate if user opens the map, then i will init the opengl. Otherwise there is no point. For games this of course is fine, but im working on a map editor and not a game. I need to have control over things. The code in previous post works fine so i will use it.

Of course for any game i will make i will leave things as you did in your examples. At least the initializing.
But yes, for map editor i must do things differently.

[User137]

I don't know any map editor (or any other software) in existence which would discard rendering context Not even Starcraft 2 map editor when there is only trigger/script editor window open. Exception is fullscreen resolution change.

At the meantime with nxPascal, work on Edit3D has continued. Solved the polygon picking and other matrix math for all cursor controls. Camera, objects and selected vertices can be moved and rotated. Selection with rectangle region, using gluProject(). Periodic fighting with small bugs etc... in editor code that is. It is very very rare occasion that i find bugs in nxPascal core. There are still 0 known ones.

[hwnd]

Is it possible to load "tex" textures from memory? (Pointer).
Atm i see only "LoadFromFile" or "FileName" everywhere.
If there isn't, you should add this possibility to load texture data from pointer.
User will supply W, H and maybe transparency (on, off) and bits.

I tried right now to mess with these NPOT textures to see how your engine handles that and im unable to load texture from pointer.
I will temporarly try to load it from BMP and see how it works. If it will work..
I tried to render something NPOT and i see only black box or even nothing. Dunno, maybe my code is faulty.
But tile loading which are 64x64 is ok. I modified it for NPOT sprites.

[User137]

It should be possible to load from TBitmap. What happens when texture is loaded from file:
1) New texture record is created to the array, via AddTexture(). If you leave filename empty, it will skip the texture loading but keep the empty record for your use.
- Internally this will fill the record's Data pointer. You can see more TTexture details in nxGraph if you wish. Most of that is relevant for next part. For example if your data would be only RGB (in that specific order 3 bytes per pixel), then you need to set:
values=3, format=GL_RGB, intFormat=GL_RGB. Then the sizeX, sizeY, Width, Height by your image.

2) Calling Restore() will push the data from pointer into OpenGL's memory. Unless you set toKeepData for texture loading options, it will free the data from pointer.

If you would have a more general function in mind that i could make to simplify all this, i'm open to suggestions. I don't know.. like this?

function AddTexture(name: string; data: pointer; width, height, values, format: integer): integer; overload;

Internally some images might have reverse order of bytes, such as BGRA. Therefore format should propably be given, as long as it's found from GL header. At least you don't need to worry about linear/nearest or mipmapping, that's already dealt with the loading options and Restore() for you.

[hwnd]

Yep, such overloaded function would be very nice.
I looked around in sources and found the struct, but i don't know if i may be able to try it out today.
Maybe after work.

But as i said such function will not hurt.

[hwnd]

@User137

Is the path finding in nxPath OK to use?
Too bad that it doesn't have enough comments and / or example included.
I would like to use it for simple tests but this "node" thing seems pretty complicated for me and i don't know how to fill in parameters.

[User137]

Did you check the pathing demo? It is ok to use but it will not work if you have several heights or unnatural shapes. It is only made for flat tile-world for now.

pathfinder:=TTilePath.Create;
pathfinder.SetMap(cMap, W, H);
pathfinder.SetCell(x, y, 1); // 0 is passable, 1 is wall
// Then you call
pathfinder.GetBetterPath()

...which fills TPath record for you. Count of nodes and array of TPoint, from index 0 beginning to end.

[hwnd]

Sorry.
I didn't notice the pathfind demo. And again because i code in very late at night, im tired and sleepy.
I should sleep at nights. But i come from work, eat, and turn my pc on and when sun slowly rises i go to sleep.

But what is the difference between GetPath and GetBetterPath?
One finds "blocky" path to target and other one with "smooth curves" or direct?

[User137]

The pathfinding algorithm is heuristic for high speed, never attempts to find a perfect path, and that should be cool for most games. There are cases where path is more optimal when search is started from end to start, instead of start to end. GetBetterPath() makes attempt from both directions and returns the shorter. (And because of that, it is a little slower. Although in the case of pitiful small map like 64x64 or so, it is practically instant.)

Either way, i have tested the algorithm on very complicated labyrinths, and even on a loooong spiral map. It does find the path in all the cases, unless the maximum node allocation is reached. It is quite high by default.