Re: Graphics mode 257 memory address(es)
> First is the bulk of such a library. If I have a small demo that requires a
> virtual screen and I want to send it to the list
for
> evaluation by all you out there, I'm sure most would prefer it to be as small
> as possible. This can also be significant
during
> downloads when one has a service provider as crappy as mine :)
I agree, its quite a large library, that is, for an Euphoria library. But are
Euphoria libraries, by definition, not very small
?
But ok, its a huge library.
> Second is the inflexibility of the library, given by the very machine code
> routines that make it so fast. Any modifications
to fit
> a specific purpose usually mean begging off to the author. Pete is a clever
> programmer, and his code embodies concepts and
> techniques whith which a user may not have enough familiarity to change. This
> goes for any such library that attempts to
reach
> beyond Eu for the hardware.
Not true. First of all, most 'pointers' it gives you, are also machine addreses,
you can acces, peek & poke as much as you like.
Secondly, it is based upon the command list principle. First introduced by
Micheal Bolin, although Pete uses a much more
effective approach (if you want to alter it often).
Just wondering, what kind of flexibility are you talking about ? Being able to
write a demo that would work with any video mode,
using any color depth ? Since, that is pretty much what it offers. What else
would you want to be able to do ? (that can not be
achieved at the most efficient way, using the commands it provides)
> Third is the educational value of plugging in a ready made library. Of
> course, everybody's got a different agenda, and a
ready
> rolled high performance option should be made available, but nothing makes a
> concept clear like doing it yourself.
>
> Anyway, simply pointing out a graphics library to use isn't really answering
> the question, is it?
'cuse me. Knowing the video memory addres, is as much educational, as knowing
the multiply tables upto 100 by heart.
Hacking the vesa interface has got nothing to do with concepts, its just a silly
technical trick. Virtual screen's, sprites,
etc. are real concepts.
And those are the concepts one needs. And playing with those is by all means a
good thing. But do you seriously smash down a
nail into wood with your hand, for educational purposes, rather than using a
hammer.
> I do agree that the available Eu libraries should be classified into groups,
> but the defenition of 'best' from the user's
point of
> view might vary considerably. Perhaps a classification more like 'beginner'
> 'intermediate' and 'advanced' would be more
> appropriate, with beginner being 'example code', pure easy Eu where possible,
> intermediate having hairy programming concepts
or
> calls to hardware, and advanced having assembler or mission-critical code.
For of all, I agree, it hard to tell which one is 'best' .. but one if always
'better' than others.
Requirements for being the 'best' (in right order)..
-- a library offers something other libraries don't (crucial, the scope of
the tool)
If it doesn't ...
-- is it faster/smaller/cleaner .. ('performace' comparisment)
Say, take my old EDOM and Gabriel's binary print & get.
Both libraries kind of do the same, only his is faster, and smaller. Mine is
thus redunant and not needed.
> One could then look to 'beginner' to learn how it's done, 'intermediate' to
> see how others did it, or to 'advanced' for high
> performance plug ins.
Isn't this what example programs are for ?
Ralf N. -- Oh well, enough about Neil for one day. What do you all think
about Jaques Deschenes (I always have trouble
spelling his name) GUI-designer based on David's early attempt. Quite a neat
tool, especially considering it is written for and
using win32lib. (so the look should be consistent)
|
Not Categorized, Please Help
|
|
