My Game API

Question

I just discovered this Forum and couldn't help but
mention I have been working on a game API since early
97. I am still working on it (doesn't pay the bills)
However, I think I have the absolutely most efficient
and robust API for games for many many reasons.
1- 100% double buffered graphics.
2- I handle Events from the Frame downwards in an internal list
100% rewrite and internal handling of
mouse and keyboard events.
3- I don't use components. Events are dispatched
from the parent Container which means 1 listener.
4 - The graphics output Thread is timed precisely
This means NO race conditions and SMOOTH graphics.
5 Layering is a product of the Graphics output Thread.
This means very little extra processing to swap
* "Component" layers.
6 100% retentiion of Alpha value on layered
components. This means you can have a
component of any shape on a Component of any shape.
7 A built in Spline() class for Gob() "Sprite"
movment.
8 SuperBitmaps()
"Scrollable Bitmaps that are larger than
the visible the display."
8 Full X/Y/Z space
9 Built in Java Object Server and class
permission registery.
10 Configurable from a simple text file.
11 Built in 100% Component swap on Event
dispatch means you can change EVERY component comprising the display in 1 display iteration. This makes changing the display on an event VERY fast and smooth. I would venture to say faster than windows
updates ALL its components (Which you can
actually see being drawn on windows)
12 AnimGob() class for animated graphics
objects.
Note:
** actually they are Gobs() of "GraphicsObjects"
I said Components so you would know what it essentially is.
*** The Graphics IO and Threading were designed
around some of the superior concepts of Amiga Copper
Lists for anyone who understands or cares :)
There are many things I don't have time to mention.
Currently I have the Object server "java.io"
yanked and I am preparing a new java.nio version.
For those who want to test the API.
(requires JDK1.4)
http://hyperbyte.ab.ca/JavaZone
Now there are some issues of course but this
displays the concept and java is fast enough
for games.
Oh yes and it runs as an signed Applet OR
a java Application verbatim.
AND I have an exact Win32.exe version.
Well one day I may actually do
real documentation.
Hava fun :)
Tony Swain
Senior V.P. of Software Development Hyperbyte inc. http://www.hyperbyte.ab.ca
Netscape DevEdge Champion Devs-Java Newsgroup
snews://secnews.netscape.com/netscape.devs-java

Answer 1

Hmm I replied to this quit a while back but it
seems to have gotten lost.
Do you use native timing or System.getMillis or do you
use timer like that at all?There are 2 timer paradigms. Native timeing is
used for Thread preemption and notification and
getMillis is used for a real time clock.
I have a new class which servers as a central
time registry and uses native timing for
what I call a "Heartbeat" timer with one second
resolution. Thus there are ATM 3 methods of timing.
The tightest is the Graphics output Thread
which has a 20ms resolution. I call this the
"Exec Constant" because it is the minimum preemption
I have found after much testing that one "SHOULD"
give so that the underlying OS has enough time for housekeeping.
Otherise you get issues such as under MS Windows where a socket
connects and you loose control of you gui because it is locked
out. This NEVER happens under HyperView. It takes care
of its own preemperion and can NEVER race. Even if you
called its paint() method from 20 Threads it should keep
running smoothly. It forces proper serialization.
The output is designed/inspired by Amiga Copper lists.
Do you use eventDispatched for catching the events?
This is good if there is only few listeners, such as
keyboard and mouse alone, but it gets very slow when
window listeners are involved.I started this after the initial release of JDK1.02.
It became obvious very quickly that there was grave
deficiencies in the origianl event model.
As such I designed my own handlers for Events
which run in their own Threads. This is WAY more
efficient because there is almost no processing done
in the mousePressed() method for example.
The Mouse listener simply accures the events and then notifies
the handler. This mean the mouse event Thread never gets
bogged down my too much processing becuase it is simply free
to keep accruing the events without worrying about what
the events do. Same for the keyboard.
Also, there is only ever ONE event listener.
It hands the events to respective handler, and
The handler processes the event.
There are 2 methods of event handling.
One which requires an Object called "Dispatch()"
And the other a more lightweight method of
overwriting the "Component's" inline event methods.
Note: I say component for clarity BUT the HyperView Does NOT
use Components at all. It has its own version which are
called "Gobs" for "Graphics Objects" This is
similar in concept to the old Amiga Bob or Blitter Object.
Do you have any documentation? I believe you don't
want to release source for such project otherwise it
would have been in the jar, correct? I want to eventually BUT I think it is too early yet.
There are too many issues I must fix. For example
Splines sometimes loose their direction in the Z plane.
Hmmm :( Thus they end up going backwards.. Shrug.
I have 5+ years of optimitation into this, but I have
not worked on it much for the past 2 years because
it doesn't pay $$$ and I have to concentrate other
paying code. However, it is my intention to
have others work on it eventually. It comes down to
I am very picky in the "A real programmer will
work 90 hours to increase the speed of a critical loop
by 90 nano seconds" sense.
The only problem
is that without the docs it is quite limited.I understand. I will post many more examples
in the next month.
I'm not
trying to snatch your code or anything, I'm using
OpenGL for my graphics, but I tried playing around
with it and failed.What failed the Applet or Open GL?
Sounds like a cool idea you have been developing.Thanks! It is my baby. The premise behind it is
simple "Efficiency" Java is efficient enough if one
takes care to avoid various pitfalls. Probelm is
there are maybe 1% good programmers and 99% bad ones.
I mean of the I should put a subrouine every 5 lines variety
the more objects I instantiate on the fly the better variety.
There are many things you do not see happening.
For example there is a complete Java Object Server
built into the Applet. THus once you run the Applet
you are at once p2p ready. However, I am replacing
this server with a new one based on java.nio.
Several of the clases I wrote under JDK1.3
Sun incorporated likewise into JDK1.4. For
example ByteBuffer and Preferences. I
am going to switch from my version to theirs.
The new nio bases server is many times better
and is non blocking. Under 1.3 I NEVER blocked but
looped around the available() method.
anyway I could go on and on about this...
You can write me for more info
(Spam avoider)
tswain(at)hyperbyte.ab.ca
Sincerely:
Tony Swain