1. GFX and SVGA
This goes to Ralf, plus anyone else who has fiddled with his GFX lib.
I think the library itself is very lucid and at least in VGA runs exceptionally
fast. However, the application I'm working on needs SVGA. I understand that
the speed loss could be attributed to no DMA for it in the library. What
I'm asking is, is there the possibility to hack it to write directly to the
SVGA video matrix, and is there better support for it (will there be?) in
nextGFX?
I think the library is wonderful; with some updating it could be a very
powerful starting point for game apps.
Thanks,
--
Cameron Kaiser
http://www.sserv.com/
spectre at sserv.com
--
2. Re: GFX and SVGA
Cameron Kaiser wrote:
>
> I think the library itself is very lucid and at least in VGA runs exceptionall
y
> fast. However, the application I'm working on needs SVGA. I understand that
> the speed loss could be attributed to no DMA for it in the library. What
> I'm asking is, is there the possibility to hack it to write directly to the
> SVGA video matrix, and is there better support for it (will there be?) in
> nextGFX?
I'm willing to code a SVGA ememcopy routine when I have time. I've also
been working on one for modeX. I've been playing around with a library
that supports many different graphics resolutions all based on unchained
planar mode 13. It should be released soon.
--
_____ _____ _____
________ /\ \ /\ \ /\ \
/ \ \ / \____\ / \____\ / \____\
/ _ \____\ / / ___/_ / /____/ / / ___/_
/ / \ |____|/ / /\____\ / \ \ / / /\____\
\ \_/ / / \ \/ / ___/_\ \ \ \ \/ / ___/_
\ /____/ \ / /\ \\/\ \ \ \ / /\ \
\ \ \ \ \/ \____\ \ \ \ \ \/ \____\
\ \ \ \ / / \ \____\ \ / /
\ \____\ \ / / \ / / \ / /
\ / / \ / / \/____/ \ / /
\/____/ \/____/ \/____/
3. Re: GFX and SVGA
--------------DE124BA892CC802AD979241B
I will answer to Cameron's question about svga & nextGFX and will tell
the new options.. also some small part of the code is in nextgfx.zip
included. Only for the curious.. and for all you benchmarkers... (please
look at it and search for points that can be speeded up... some of you
are really good at code optimizing)
--
Now you know what this long mail is about.. you can either skip it or
read it..
--
Cameron Kaiser wrote:
> I think the library itself is very lucid and at least in VGA runs
> exceptionally
> fast. However, the application I'm working on needs SVGA. I understand
> that
> the speed loss could be attributed to no DMA for it in the library.
> What
> I'm asking is, is there the possibility to hack it to write directly
> to the
> SVGA video matrix, and is there better support for it (will there be?)
> in
> nextGFX?
Yes, there will be, consider the svga to consist of different
parts.. parts of dimensions we can handle (like 320*200)... When we go
to another section of the screen we have to do an interrupt, this slows
it down a bit. It some1 could tell us how to do a dma-pixel or a
dma-banking, please do. However it will still be faster than
Euphoria's built in pixel routine, cause it will do the interrupt for
every pixel that's not it the begin section. And we can now use
e_mem_copy, this means we can do the see-through effect *very* fast...
All of these new tricks and techniques will be there because of Pete
Eberlein & Micheal Bolin. I am only writing the most flexible & fastest
interface possible for most purposes.... the new command list concept
will able us to do some preparations so when we actually have to execute
the commands, it will be lightning fast.... :)
Althrough i can now use the see-through memory copy, i will also
support compiled sprites. The new compiled sprites totally split it up
in different sections (some small stuff poked (faster), some big stuff
memory copied and some stuff with see-through effect memory copy), there
we also be an option to compile the sprites to a plotting script.. we
can draw it at any size we want. This is very good for font-systems :)
If nextGFX is done i will create a font-library using nextGFX, and
maybe also an window-library... (with the virtual screens and stuff this
should be fairly easy)
> I think the library is wonderful; with some updating it could be a
> very
> powerful starting point for game apps.
nextGFX can be expanded with your own routines very easily... and so it
can have a lot of different purposes... It will consist of three
parts...
+ AllModes.E
(Video Modes DataBase, Command List Environment & Executor, Basic
Graphics Stuff)
+ nextGFX.E
(virtual screens, sprites, video mode selection, etc.)
+ gameFX.E
(real collision detection, maps, acitvating sprites, compressed
sprite & screens & map to a file, AI, etc.)
The real collision detection will detect collision to pixel level..
but it will also give to relative distance... (howmany sectors away)
The map engine will use sectors... with the rule that everything on
your current sector and neighbour sectors will be activated....
AllModes.E is general purpose graphix lib
nextGFX.E is used for advanced managing of screens & sprites, etc.
(and will use allmodes.e built in scripting & executing tools...)
gameFX.E is specially for most if not all types of games...
I hope i have informed you enough to avoid any rising questions..
Please e-mail me if you want me to clear some part of this up.
I've attached the part of code i already have.. take a look if you
want.. it includes a test.... :) (It will only copy a virtual screen to
the monitor 1000 times to measure the framerate)
Ralf Nieuwenhuijsen
nieuwen at xs4all.nl
--------------DE124BA892CC802AD979241B
Content-Transfer-Encoding: x-uuencode
Content-Disposition: inline; filename="Nextgfx.zip"
