Manifesto:

Everybody has his/her own preferred way to
think about an interface to the graphics,
sound and other hardware in a computer.
Because of this, many people write their
own wrappers on top of, for example, DirectX
or OpenGL.. and then call their own functions,
rather than DirectX or OpenGL specific
functions.

This has some advantages:

1) you retain host API (or hardware) independence,
i.e. if someday the trend moves from DirectX to
OpenGL or viceversa, or to a new API (or even host
OS, or directly programmed hardware), all of your
code will still work on the new API or host OS/hw,
provided you rewrite just the wrapper's functions
for that specific host.

2) you retain true OS independence, i.e. you
can write that wrapper (that now we will call
"set of functions ideal for you") for Dos,
accessing the hardware directly, or for Linux,
or for BeOS, or for OS/2, etc.. and still have
your programs work without any, or almost any
modify. You need to write a specific library for
each of these OS's, and then forget about which
OS will host your application, because in any
case the code that you will write will interface
anyway to your well-thought library of functions.
This way you can have a broader range of users.

3) you increase portability also towards other,
very different hardware, such as Macintosh,
Amiga, etc..

4) you code using an interface for you very
intuitive and familiar, having been designed
by yourself, not by others.

Following this philosophy, you will soon see
that from a simple wrapper you end up more and
more towards a true OS.. first running under a
host OS, but then, ideally, closer and closer
to the hardware. The limits to this are practical
and today we see the maximum historical extension
of these limits (at least on the PC), but nothing
says with sureness that things won't change in
some years, or if you migrate to another platform.
In any case, the advantages of working in this
personalized and modular way are many, too many
for some programmers to abandon it and embrace
fully an existing API, like for example DirectX,
and make your fate totally depend on its one.

Considering all of the above, with this board we
want to create discussions, and expecially share
practical and valuable help, so that everybody
could create or improve his very own personal
concept of "OS" (for simplicity we call it
"game OS", or "game API", but the concept applies
to demos or utilities nonetheless).

On this board there may be some discussions about
how everybody sees his own API implemented ideally,
but we really hope that this kind of discussions
will be limited as much as possible, and to see
instead useful, probably mostly low-level or even
very low-level informations on how to implement
some important aspects of everyone's OS, which will
then be personalized by every programmer for his
own OS.
Such informations may range from "how to access
to undocumented host OS functions" (with all the
compatibility issues involved), to "how to command
the graphics hardware directly through the HAL,
bypassing DirectX", to "how to get reliable and
fast timers under Windows", etc..

The common denominator among all the posters of
this forum is the common idea that customizing
the set of functions used to create a multimedia
application is fundamental for us, and to share
as much help as possible to improve everybody's
chance to make his own very personal interface
as much ideal as possible.

In short, we like to have a personalized programming
environment, which we will call a "game OS" for
simplicity (from a wrapper at the begin, to a full
OS at the end.. everybody can find his own place),
and we share informations to help each other to
reach our own very personal goal.
Posted on 2002-01-14 20:38:10 by Maverick
This forum has a focus on Win32asm, and I personally think OS stuff should be in the Heap - even with having a great interest in the topic myself! There are many great resources on the web for OS coders, as well as all ASM OS's to work on. There are certainly many other coders around the world with the same view as you. If you need some links just shout out. ;)
Posted on 2002-01-14 21:01:39 by bitRAKE
this forum is about assembly under windows (currently only 32bits ^^ ) If you wish to develop another API for gamers to use, please go right ahead but it belongs in the game programming forum.

thx.

-H-
Posted on 2002-01-14 21:34:33 by Hiroshimator
Following this philosophy, you will soon see that from a simple wrapper you end up more and more towards a true OS.

No you don't. Your wrapper can be regarded as a "tier", and is similar to the concept of "n-tier programming", which is popular particularly in database apps. By slowly refining or slimming down the tier you simply move closer to using the API directly, not morphing the OS. To end up with your own OS you would have to start writing the layers between your tier and the hardware, which moves away from the portability you were talking about.

Personally, the only reason i write a wrapper for any API calls is either:
- to get away with passing less parameters to the function, effectively making some of the parameters "optional" (the wrapper takes care of inserting the default values)
- the wrapper is a macro, this can make regular code a whole lot easier to read

By writing a wrapper/tier, you effectively slow down the process of accessing the API, and can make your code more prone to bugs. There would be very few programmers who develop a wrapper to the extent you were talking about, and i think you will find they are not good at working in teams :) I think your concept is a little too abstract, you have kinda lost your way while thinking about it :)
Posted on 2002-01-15 02:38:16 by sluggy

This forum has a focus on Win32asm, and I personally think OS stuff should be in the Heap - even with having a great interest in the topic myself! There are many great resources on the web for OS coders, as well as all ASM OS's to work on. There are certainly many other coders around the world with the same view as you. If you need some links just shout out. ;)

Consider yourself shooted :grin:

No, pal, you know what I mean ;)
Posted on 2002-01-15 05:54:12 by Maverick


Consider yourself shooted :grin:

No, pal, you know what I mean ;)


argh.. you said "shout", not "shoot" .. so my joke didn't neither apply :grin:

Anyway, thanks in advance for the resources/links :tongue:

Greets,
Maverick
Posted on 2002-01-15 05:55:34 by Maverick


No you don't. Your wrapper can be regarded as a "tier", and is similar to the concept of "n-tier programming", which is popular particularly in database apps. By slowly refining or slimming down the tier you simply move closer to using the API directly, not morphing the OS. To end up with your own OS you would have to start writing the layers between your tier and the hardware, which moves away from the portability you were talking about.
Adding an option doesn't reduce portability.
You don't have to get rid of old code if that
is not necessary.. but just provide added
functionality (and a choice, either automatic
or manually configured).
It's like those (there are some) that make
you choose if you want to run your program
under DirectX or OpenGL. Maybe your card has
better drivers for OGL, thus you (or, better,
the program automatically) chooses that.
Again, adding an option doesn't reduce
portability, and is not a waste of development
time per se. It depends by the case, and
careful analysis is always necessary (in
everything that you do, not just this..).


By writing a wrapper/tier, you effectively slow down the process of accessing the API, and can make your code more prone to bugs.
Honestly I didn't ever see an abundance of
bugs in my code (this may not sound modest,
but let's say I re-read and test my code
carefully); but I saw and see thousands bugs
in the host OS (Windows), for example. So
why should I be concerned with the risk of
getting some more bugs using a macro or a
pseudo-macro; more than being concerned with
the bugs already present in the host OS?
Also, I could very well tell you that using
the host API is more prone to bugs, since
you will never have the familiarity with it
that you would have with your own interface,
and thus will be more prone to make bugs.

I think your concept is a little too abstract, you have kinda lost your way while thinking about it :)
Well, been doing it for a lot of years, and
it proved correct by real life every time.
But I have no problems with your disagreeing,
let this be very clear.

Greets,
Maverick
Posted on 2002-01-15 06:00:13 by Maverick
So why should I be concerned with the risk of
getting some more bugs using a macro or a
pseudo-macro; more than being concerned with
the bugs already present in the host OS?
You have an absolutely valid point about the OS, but in answer to your question: we all strive to be good coders :)
You worry about bugs when you go commercial with a product or project, and you have to start supporting it. Then those bugs come back to bite you :)

I agree with your point about a programmer knowing their own interface/wrapper and being more productive with it, i have just always been one of those freaks who learns and uses the API directly almost exclusively (i first started doing asm back in the days when 'APIs' were known as 'ROM routines', and they didn't have names, ahh the power :grin: ).
Posted on 2002-01-15 06:22:51 by sluggy