Structure and Design

[MuteClown]

Ok, well for the last two days i've been trying to put together the beginnings of my own library, which i hope can then be developed into an engine. It uses SDL and openGL, atm im just dealing with the design structure and the easy(er) sections camera and input. I was hoping if you all could give me some hints and such.

The plan i got atm:
I want to keep everything as modular as possible, with each what i've just started calling devices((input, camera,renderer etc..) dunno if its really the right word but a well =]) So what i've started implementing is a device manager which is used to fetch and post events to the device. I was thinking of having some sort of Event stack or queue, to post and fetch from. With a property that tells if there is any events to be fetched. This is to be implemented via an interface.

EDIT:
Also now i was thinking of using an observer pattern in the input class to notify when there is an event. This is so i don't have to keep checking if there is input, so the input device will let me know when there is input to handle. I'm also going to make the device interface a generic interface, since each implementation of the interface is most likely going to be using a different type.

So far the camera device isn't looking to bad, i've just kept it simple for now; still trying to organize the input device.

So its this an OK route to take? I fear i might be over complicating things, in theory i think its going to be good, but what do you guys think?

[code_glitch]

So I take it we are going 3d?

Sdl and OGL in the same box, like it, I'm on the same boat here with Prometheus - sdl for the earlier stuff and OS stuff like event handling, and OGL for speed. Nice. Heres my good deed for the day: do not, I repeat do NOT use sdl_surface, or sdl for graphics AT ALL apart from loading nice file formats. It will give weird results - period. I know you can get it to work, but is it not easer to just go OGL?

Event stack or queue, to post and fetch from

Hey man, sdl has this, I would just write an interface to it - pie easy here

observer pattern in the input class to notify when there is an event

I see a prime target for some neat and low resource multi-threading here don't you?

If you habe any Qs and want As just post or whatever, if you need some multi threading code, then same thing. Anyway, you get the idea.

[MuteClown]

Yeah im going 3d, i probably should of made a good 2d OGL/SDL engine. I thought i may as well just go 3d, since i see a few 2d libraries i can use anyway =]
Im going to wait on doing threads until laters, since im not as confident with them, but i do try to design with them in mind

Yeah, im probably going to be throwing many questions out here, to get input from people with more experience.

Edit: would also help if i wasn't referencing a model-view-controller pattern instead of a observer one *sigh*, being brain dead is blissful until you realize it

[code_glitch]

BTW: A thread is the easiest thing ever... Here is some example code:

program Test;

{$Mode Delphi}

uses
    cthreads, classes, crt;

type
    TSomeThreadClass = class(TThread)
            ct: int64;
            
                procedure Execute; override;
        end;

procedure TSomeThreadClass.Execute;
begin
    //Main stuff to do Ie. Kernel
    
    //Kill the thread when Kernel_Kill gets word
    Terminate();
end;

var 
    SoundThread: TSomeThreadClass;

begin
    SoundThread := TSomeThreadClass.Create(false); //Create the thread, s
    SoundThread.Resume(); //Execs the Thread.Execute procedure. Nice.
    
    //Stuff continues
    
    SoundThread.Terminate; //Tell thread to stop
    SoundThread.WaitFor; //Wait until thread exits
    SoundThread.Free;
end.

piece if cake really