There are no plans with this Voxel Engine whatsoever.
If someone is seriously interessted, I can provide the code, but better thant that, I can advice how to write this. The code itself is not very helpful, without understanding what is going on.
It is not using any polygons or OpenGL. This is software rendered. I think it can be done on NG Amigas or WinUAE in acceptable speed at good quality.
The reflections are traced with the landscape upside-down, and are mixed with the blue-water-tinted ground of the water.
It's quite slow at redrawing the planet. You can see the frame rate in the screenshots - the earlier ones are at "subdivisions=5" and run at about 5fps. The last screenshot I posted is subdivisions=7 and is showing 0.7fps. That's way too slow to try and fly around, but 5 subdivisions is acceptable (and I'm running a 600MHz SAM here, so results would be better for most people)
You can export to Blender too, but I haven't tried that.
Guess Thilo "wanderer" Köhler is far to bussy with different projects (HD-Rec, Amiblitz, NTUI (gui libraries/includes, A/A++,....). So I guess it is not motivation or lack of hardware. It is more a lack of time. But... to my knowledge Thilo (Wanderer) does work on PPC related stuff... His A/A++ progamming language + IDE can generate code for different platforms. However I think Thilo is a very talented coder/engineer and it is a pitty that he does not focus on OS4.x related stuff. But as he does it all in his spare time, he is free to do so and to decide what to build/code.
I would, however lend him my SAM440, as a new machine will approach soon...
The "crash" at exit is because of bad coding. I get this a lot. The reason is, that the main_widget is not deleted before exit. You need to change it, either:
int ret = app.exec();
delete main_widget;
return ret;
I am trying to build fracplanet here on my Sam, but I'm confused about the boost dependancy: Did you just use the clib2 static version from os4depot, or do you have your own version lying about??
I think the problem with the mouse is, that QCursor::setPos() is not implemented (yet).
EDIT: Actually now we are at it: How does one set the Mouse position in a system compliant way?? Just modifying the screen->MouseX and MouseY doesn't seem to do the trick...
alfkil wrote: I am trying to build fracplanet here on my Sam, but I'm confused about the boost dependancy: Did you just use the clib2 static version from os4depot, or do you have your own version lying about??
I have a minimal version containing only the bare minimum for fracplanet to compile. I'll send you a copy when I get home.
Quote:
I think the problem with the mouse is, that QCursor::setPos() is not implemented (yet).
EDIT: Actually now we are at it: How does one set the Mouse position in a system compliant way?? Just modifying the screen->MouseX and MouseY doesn't seem to do the trick...
The only way I know, is you can "lock" the mouse to a particular area. If that area is only 1x1 pixels in size the mouse will move there (I'm not sure if the mouse has to move once before it gets repositioned). The tag is specified in the OpenWindow document, you need to assert it every n IntuiTicks if you want the mouse to stay trapped. For moving you can probably specify the area and tell it to stay for the minimum (1 IntuiTick). If it repositions immediately that should effectively just perform a move.
The "crash" at exit is because of bad coding. I get this a lot. The reason is, that the main_widget is not deleted before exit. You need to change it, either:
I thought it would be something like that, but I couldn't find the exit routine anywhere! I suppose that might account for it not deleting its widget though.
The thing is this: Top level widgets (those shown on screen) needs to be deleted by the app. This usually takes place, when the QWidget goes out of scope like this:
int main(bla) { QApplication app(bla); SomeWidget widget; widget.show(); return app.exec(); // widget gets automatically deleted when function returns }
All child widgets will get deleted with the parent, which is why the children needs to be allocated with code of type:
Is the fact it is using new to create the widget a problem, perhaps? So it needs a manual delete main_widget? (I think delete is right, my C++ knowledge is appalling)
Looks like it is relying on garbage collection to destroy this...
Is the fact it is using new to create the widget a problem, perhaps? So it needs a manual delete main_widget? (I think delete is right, my C++ knowledge is appalling)
Yes exactly! When creating a new object with "new", the object will not get deleted when the variable goes out of scope. This type of code is stupidly relying on the system to automatically clean up the resources, which works fine on Windows and other systems with automatic resources tracking, but not on Amiga. Amiga needs clean code!