Re: Sprite & Screen techniques & EU Games
>In response to Ralf's comments about my mode X library, it would seem that
>I won't be needing a sales staff with Ralf around to voluntarily promote my
>work 
Your welcome, but I'll review the updated mode19 lib by Hollow Horse
software today.
>In my opinion, every program should be written with a specific graphics
>mode in mind, and use an appropriate graphics library. I think it would be
>better to use a library that is fast and has a lot of features limited to a
>single mode than use one that runs slow but supports every mode. With all
>the libs out there, someone should take a look at each and compare them,
>list features and post the results on a web page or something. This would
>make choosing a specific lib to use easier for some people.
With command lists it makes no difference if you design it for one or more
video modes.
You could one general execute command list and different version of all the
other routines.
Any video mode specific lib will give its routine iD's to a routine in the
general upper layer called "IndentifyNewEmployee" or something.
The routines for every video mode should be very very low. (but all the same
usage over the different video modes)
But have an option for extra methods or actions. (like PanTo in ModeX)
The a generic layer for the sprite and virtual screen managing (don't read:
virtual screen copy routines)
Every graphics mode employee will also have to take care of the virtual
screens.
But those aren't made for every mode, those are in a few libs. Most Video
Mode employees can work with the sequence screen managing (the fastest way
for the built-in graphics modes), mode19 and SVGA can work with an memory
screen library, and modeX has to use its own specific planed memory screen
routines.
I say it is possible with no RUN-TIME overhead, only creating command list
can be a bit slower, because routine pointers seem to slower than a direct
call (Robert! Please make them faster) to a routine.
And off course Euphoria 2 Beta has to finished will you even be able to bind
this stuff, but at the time such an engine is finished, and some1 wrote a
game for it, the beta version will already be available.
>On the subject of asm... using third party libraries is a bit tricky
>depending are whether the libs are written in 32-bit or 16-bit code. The
>docs for the mod player attached to Ralf's post were obviously written for
>16-bit programs. Converting to 32-bit asm may not be trivial. I haven't
>taken a good look at Microsoft's .lib docs yet, but if those are 32-bit
>code, then linking them might be very possible.
Oops, I was thinking 16/32 bit only mattered for compiled machine code. So
that it has to be compiled for 32-bit PM, instead of being written for
32-bit PM.
>As for the discussion on a Descent clone, C.K.L wondered about the author
>of the texture mapping demo, yes it was me. Euphoria, with the ability to
>link to machine code routines, makes just about anything possible, as long
>as you know asm. As I mentioned above, all asm has to be 32-bit to be
>compatible with the CPU mode that Euphoria runs under. I think a virtual
>reality engine for Euphoria may not be long in coming, as I have seen a lot
>of talent displayed so far. Everyone, please keep sharing knowledge and
>code, so we all may benefit from it. I'm thinking I need a reference from
>Plato's "Allegory of the Cave" right here. I for one have been continually
>inspired by stuff I see other people doing, though I have to agree with
>Michael Packard - someone finish a game!
Maybe I should finish my clone (develop a beta version using one of the
graphics engines, preferably yours ?)
Did any1 like its game play, because I know the graphics stink.
I only paid attention to the game play, any comments ??
Ralf
|
Not Categorized, Please Help
|
|
