What are you puting this on a java forum ? You may ask.
The answer is if i don't do it in C++ then something i have great pride for will be severely cut from me.
But why are you betraying java ? You may ask again rightfuly.
The answer is that im trying to do an engine in C++ the way im used to program in Java. The problem is that in all the C++ forums i post people are completely cluless of what i intend to do because im thinking in Java.
First limitation i cant use classes dynamicaly in an easy way.
Second limitation i want to do an event dispatcher similar to the one in Java3d but i can't use threads.
Heres a trace of the execution of the engine im planing:
open log file for errors
read config file
That's easy even C++ has defined file operations in the standard library.
....look for os specific info
....look for os layer class to use NOTE: this can be SDL, Allegro, OpenGL, etc
load os layer class at runtime
bind os layer class to os layer independent interface NOTE: use os layer independent interface for now on for everything
This could be pretty difficult if you'd like to support all OSs and all libraries.
BTW how would you like to discover on what OS are you?
initialize game screen
initialize game console
initialize game devices
prepare yourself for errors. Errors called untestable interactions between input library and input devices, on various OSs.
read config file for extensions to load
load extensions in order they apear in config file
....load modules NOTE: modules are function libaries that obey a certain interface and access only other modules or game functions, so they are os safe
Java programmers start here.
....load resources
....register module ids and module startup status (active|inactive)
....bind module classes to module class interfaces
....register resource ids and memory usage policy (permanent|load-on-demand|volatile)
And don't forget to protect yourself against all weird memory errors. Could be nice to count allocation and releasing of memory, so you'd at least have some idea about memory leaks.
start event loop
....poll devices
....enqueue events
....preprocess event queue
....if exit event leave
....dispatch events to modules
....repeat
This is rather straightforward in C++. Simillar to Java.
finalize and exit
I must load the os layer code at runtime after reading the config file, possibly checking for the name of a class then load it and initialize it then cast it up to a universal os layer interface and use it that way.
Correction. You must start launcher and then choose the right file, or DLL, or something.
Don't have a clue how to do this in C++.
The modules must be loaded at runtime after the engine check for a list of modules to load. Each module implements (inherits in C++) the universal module interface and must be casted to one of these after being loaded.
Im clueless here too.
It looks like you are.
first you'd save the modules with extension .PDB. You'd write at start of each compiled module pointer to inside for entry point of the module. It would be 8 bytes (one 64 bit pointer).
Then in the loader you'd create table of pointers.
PROTO Pointers{
some_UGLY_module1 DWORD
some_OTHERUGLY_module2 DWORD
}
Then you'd look for a file inside of what would be description of module names and file names, and of course what CPU is supported for module. It might be nice idea to have IA32 and MAC modules in different directories.
You'd look at hash of the file and if it will be correct you'd load module into an array. If it would be incorect you'd post a message: "Module isn't loaded. Module is either corrupt, or some band of retards added hastilly new module into a directory and didn't updated neccessary informations. Try running setup, and choose repair modules."
If it was correct, you'd write into that above table entry point of the module. You know it's in the array, in simillar way as it was in the file, so pointer to array+last 4 bytes of the pointer from PDB file (written as low endian) should be entry point to the module in the memory. Right? (its custom to write that entry point as differece from start of the module not from the start of the file. Ie from start of the file it would be 8, in reality it should be 0.)
BTW PDB is abreviation for portable debilism. If you'd be implementing ones you'd know why.
Of course you could have it somewhat easier, if modules would be just a DLL files with predeffined entry point. This means entry point would be entry and outry point would be outry.
Or something like that. ^_^
That table would stay, you'd just use standard DLL loading mechanisms. If your application would crash you should do every effort to unload that DLLs. I don't recall if on current XP is guaranted it will unload all libraries if application would crash, It could run on some OSs that might be less paranoid.
PDB is easier. If your application would crash it will take PDB with itself.
Look at JNI interface, it could give you some ideas.
Finaly i must implement an event loop similar to the one described in the trace but without using threads.
Not even by multiplatform thread libraries? BOOST for example is cited as a one of more standard ones.
As you guys can see im in deep shit here.
I may try to convert this stuff yo Java later for my great releave but now i need help doing it in C++.
Any ideas ?
You would do all of that just by yourself? It's work for at least half year, or so. (more likely 1.5 years, then again we don't need to count all that debug and all bug repairs for various OSs to development... )
What they would like to do with this?
It might be faster to write it in Java then port it to C++.
