Re: [Challengeos-developers] what to do ...

[<Gre...@gm...>]

Hi!

Sorry for the unusually long delay. I've had a hard disk crash last 
weekend that carried a lot of data away and I'm still struggling to 
recover from it. I'll not be able to recover everything, though :(.

wael oraiby wrote:
> This is a free software so do with it what you want ;)
> , for the tasking and etc.. , about the memory manager
> i will try to do some work on it when i can get a free
> time , cause currently I m under lots of presure , the
> game engine is growing up fast and as it grow it
> requires more time , and until I can make use of a
> good algorithm (not sure of BSP yet since it requires
> the hell lot of time compiling and requires lots of
> work and time) , so basicly I m thinking in a
> different approach , anyway hope I can make it ! 



> for the operating system I m surely agree with your
> structure , it's revolutionary , however we still have
> a long road to travel to get there , we need more
> coders maybe , currently we must focus on making
> memory manager , interrupt/signaling system and event
> handler services and of course scheduling , those the
> basic keys for any operating system , the file system
> will surely requires lot of time later , but currently
> we must get those stuff working first !

True. But I believe that when we know the requirements for the software 
we may be able to fulfill them better on the first attempt. So the 
discussion we recently had here hopefully pays itself off.

The memory manager and interrupt management have highest priority right 
now. The low-level side of interrupt management is almost done, I 
assume. We should be fine for a while if we provide an assembler wrapper 
for interrupt handlers that saves the registers to a data structure, 
calls C code in a save way and restores the registers from that data 
structure afterwards.

The event handling stuff is lowest priority now. I'm not sure whether it 
should be in the kernel at all. Maybe it's better to leave it at 
application/component level and build an ordinary syscall interface instead.

The file system work can start only after some device drivers have been 
written. I'll try to put up a framework that should keep device drivers 
seperate from the main kernel at source level as far as possible. The 
reason is that the kernel should be linked at boot time in the future 
and not at compile time.

> 	Another thing , where is your game engine going now ,
> you were using SDL and OpenGL last time we talked
> about it , as well as you were coding for moonlight ,
> so what happened to your engine ? and what about the
> university ? work :) and ...

I've lost a lot of work on the engine because of the disk crash. But 
I'll recover from this I think. Before the disk crash I've been able to 
convert blender files to levels (only texture support was missing). 
Loading these files worked as well as basic view frustrum culling. That 
was all lost in that stupid hard disk crash (th drive is less than a 
year old).

> 
> well cya soon , i hope :)
> 

I hope you understand the delay I had. It has been a quite stressful 
time recovering from this accident.

> -kintaro
> 
> __________________________________________________
> Challengeos-developers mailing list
> Cha...@li...
> https://lists.sourceforge.net/lists/listinfo/challengeos-developers
> 
> 

Gregor