Threads..

[M109uk]

It is possible, i tryed build it in to a class.. i more than likly missed something out in my class, specially when i tried to get multisampling working, since then my oringally engine didnt work :s

Although it does'nt explain why the NeHe examples did'nt work when i compiled them with 3 different headers, in fact i recall the executable that was included did'nt work either :?

Yeah, i had a quick look at the code required to create a context in linux and safe to say it was giving me a headache.. i know SDL supports many platforms, but does it require much alteration in my engine to support other platforms?

[Chebmaster]

I didn't look into SDL myself yet (I am happy with my moster of a window manages as it is... Although it took me years to build and fine-tune it) but I hope that SDL's main purpose is to protect you from these bloody details.

Still, recheck your OpenGL calls flow. If it's wrapped in a class, attach to all your code block a short WriteLn() to console or log file and see if the blocks order is correct. May seem a bit tedious, but this approach could save you many hours worth of debugging.

Btw., my program is peppered with constructs like
if VerboseLog then AddLog('Some witty comment' + SomeParameter);
, where VerboseLog is a global boolean var. You may think that debugging allows you the same and more, but my method paints a complete picture of what happened after what. Very useful.
I'd recommend using something like this in your OpenGl initizlizing code. So in case one of your users with different driver/videocard runs into problems, all he need is to turn verboselog on and send you the log file.

[M109uk]

It seems to do all the window creating itself, well at least on windows i havnt tested it on linux yet, since my linux box is in several pieces on the floor :s

I am hoping it deals with these things, it will save myself from a lot extra debuging, and headaches :roll:

What i have done is all the systems within the engine are in seperate units with their own initialization code, so for example the particle systems is in XParticleSystems.pas, with a TList class that holds all the particle systems, this is created and destroyed in the initialization and finalization of the unit, i have placed a log event in every unit that does this, how ever for seem reason the units get initialized at different times not matter where i put the uses clause in the dpr, for example in both the projects i have:

uses
  XParticleSystems,
  XLightmaps,
....
  XModels;

how ever in the log, in 1 of the projects it would say that the models class was created first, but in another project it would say the lightmaps was created first, for this reason i spent 2 weeks debuging, due to several access violations, because for example the models unit uses a class that gets created in the lightmaps unit.

I found this same problem was why one of my attempts of creating the window manually failed, because it was creating the window before initializing OpenGL.

My engine seems to be riddled with little bugs that jump out of no where :s
last week i rewrote my engine, so that its no longer built within a library, for some reason i had a for loop within the render procedure that always violated the array range, how ever i never got an error about this until a month later when i started on the particle system..

I will take your advice about the verbose log, thanks it would help in the long run.

[Chebmaster]

Also, there are two more tricks:

A.) Take the C way, break your units to header and body parts, and {$include xxx} them into a single unit. IMHO, this approach is better for rthe stuff with many inter-dependencies than the standard Pascal units way. Minuses are you have a heap of files and you need to watch the order they included and take care of forward declarations.

B.) Get rid of initialization..finalization blocks in favor of manually called InitXXX() procedures. This way you will always be in control.

The more I see tha more I believe that a Pascal unit must be a bigger thing that people usually make it. It should be a self-sufficient "black box" with no "extra" dependencies, unaffected by initialization order. This may be as small as 50 lines of code or as big as 9000 (my personal record for single unit - it consists of dozens include files).

If your units do not match these criteria, merge them.

[M109uk]

I have a few of the bigger units such as the lightmapping, split in to several files and included into 1 unit, i really only do this if the unit is getting to big to keep track of.. i normally prefer not to do this with the smaller units because i just find it a pain to keep track of everything, and delphis code completion does'nt work with the seperate file either (me just being lazy )

I intend to get rid of the initialization blocks at some point soon, specialy now that there is soo many :s (really is a bad habit of mine)

Sadly my entire game & engine does'nt have a single self-sufficient unit (well maybe 2), i have built my engine in a way that i dont need to worry about creating or render *any* part of the engine, all i need to do in the game is create then engine class, initialize it and then load the required data, the engine takes care of everything else, the down side is that when i create an editor i have to include every single file in the game, im sure it is probably bad practice on my part ops: