Holy Macro's batman.
Macros are handy for creating automatic names and defining constants. These are things most people don't do because they use a normal IDE or are lazy. Either way
I've used macros a lot in embeded systems which use C or C++ (I prefer the later without the use of constant objects of course that is a huge problem with an embeded system).
For example if you are defining a GUI (Yes you have to do that often in an embeded system). It's much easier to do this
[/code]
#define SHOWB(M) _show_##M
#define SHOW(M) void SHOWB(void)
SHOW(RootWindow)
{
}
[/code]
Than it is to type _show_RootWindow
void _show_SensorSettings(void)
void _show_...
And then to define the base name over and over again. It makes for a LOT less typing.
Especially if you say #define ROOT_WIN RootWindow then if you decide to change your root windows name you just change it in one place. This seems like a C thing but it works just fine in C++. Especially when you only have 16K of RAM and 64K of FLASH to deal with. Saves LOTS of memory it turns out (since you don't have extraineous definitions) and makes the code a LOT more readable (and easier to modify and extend).
Alhexx hmmmmm
I really don't know I believe Halkun has refered to this in gears but no specific details exist.
I believe he said it went something like
Load Kernel
Kernel Loads Game module (also known as Field module)
Game Module starts up basic game loop (IE wait for person to start new game or load old one). Then the game module loads in a FIELD location. If a combat situation arises the GAME I think the game saves a few variables then dumps the field engine and loads the battle engine. Mini games are done much the same way. Essentially the current field module gets dumped and the minigame gets loaded. The the field module gets reloaded and it's state restored as needed. The Game is the field engine I believe is the best way to look at it. The kernal has the game state information in it. So if it's in the START state it grabs the information in the script about start up and begins from there (Shows the intro movie then loads the train station location and the game is a foot so to speak). I believe some things in the kernel are understood though. (IE game state information for example).
I can't verify if this is what actually happens however
A remake of the engine might not need to use the module swapping, because PCs have a lot more memory than consoles.
Hmmmm no it might not need module swaping at all however the basic system intercommunication it has is needed. So essentially you'll need all the modules, you just don't need to worry about loading and unloading them all the time perhaps?
How about a Dynamic Link Library approach?
The Kernal loads the basic game 'DLL' which uses call backs to the kernal for various support functions. The kernal it'self can use in a plugin interface for handling graphics support etc. This makes the whole thing more generic. Much like PCSX and ePSXe operate under Linux and windows almost identically. The main GUI can be used to handle picking what support modules you wish to use. The ultimate in compatibility support so to speak
Cyb
