Re: 640*480 memory modes

new topic     » goto parent     » topic index » view thread      » older message » newer message

Lee woo seob wrote:

> I also have 256 color (SVGA) virtual page library, which was also made
> by
> Mr. Park. I have no experience of using it, but i heard he used VESA
> mode
> for it. SVGA mode usually does not work well in my computer and in
> Park's
> computer also. however, at least, his 256 SVGA library works in my
> computer
> works well. i saw he used dos interrupt, bank switching... etc in his
> source.
> if you want, i will sent it to you (it includes demo example).

I am very interestes in that code, could you post it or send it to me,
please... (i would really like that, to have a look)

And about the graphix mode 20, of type Grafix, it is there so you could
specify how nextGFX should configure and control their graphix output,
for some reason you may not want to use SVGA-optimized code, but the
normal built-in graphical routines (like pixel and get_pixel, etc)
.NextGFX will use those built-in routine when in a GRAPHIX mode, when it
is in a MCGA mode it will use code optimized for MCGA-mode19, when in
ModeX it will use special ModeX routines (note ModeX is only available
through SetMode, see the documentation) SVGA modes are optimized for
SVGA. (in the way i decribed before)
    I am not sure how the memory is ordered in mode 18 (euphoria mode
18)
    Maybe somebody got some docs on this ? Or just knows the answer ?

    I suppose that it holds 2 pixels per byte (the highest 4 bits are
the color value of the first and the lowest of the second) But i have
not tested nor read this. It just seems logical. If somebody knows more,
please tell me, there has to be some way this can also be optimized!

Also i will release un update on nextGFX this weekend, i still have to
document, test and make a nice demo. That update will support virtual
screen handling, using command lists, which are compiled to know as much
as we can before we have to execute the command list. The most difficult
part is handlers, which give you acces to some of the variablen and
values of the commands, after all, they have to be dynamic (for
scrolling for example, you want the offset addres of the big image to be
dynamic, that means that you can change it quickly using a few routines,
after it has been compiled!)
    When the update is totally done, tested and documented, i will post
the code the irv again and to Robert.

    BTW Were there any questions about the documentation or was it clear
??
    English is not my natural language, so i suppose that it could be
confusing at some points.

Ralf Nieuwenhuijsen
nieuwen at xs4all.nl

new topic     » goto parent     » topic index » view thread      » older message » newer message

Search



Quick Links

User menu

Not signed in.

Misc Menu