Re: Graphics mode 257 memory address(es)

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

Ralf Nieuwenhuijsen wrote:

> > 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)
>

Well, by flexibility I mean accessibility.  When I was starting in Euphoria the
way I learnt how things worked was to look at the
code. To achieve my goals, often code would need to be tweaked or rewritten
entirely.  The Neil library is very capable, and from
the outside  provides much of the functionality an experienced user could ask
for, but I can't imagine what I would have made of it
back then... :)  Sure, it probably would not need to see the programmer's hand,
but what if....

Of course it all depends on one's perspective.  I like to keep things simple and
concise, and as compact and fast as feasable.   To
this end, I sometimes make includes specific to programs with any modifications
thus isolated.  It also helps me to understand
what's really going on.

> > 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.

Wether you know it off the top of your head or spend hours finding it in a book,
it is still important to know why it's there and
what it's good for surely?  I have a friend who says he did not do well at maths
in school because he used to think he was meant to
understand the formulas or tecniques he was told to use.  He would not accept
that one simply plugs in numbers and follows specific
steps for a solution.  He sought the deeper meaning, and in doing so, failed
quite miserably.  This led him to assume he was
mathematically inept, a shame for a clever mind.  My point is that one may
understand a concept better by being aware of it's
fundamentals, for some people it's the only way.  I'm much the same myself.

> 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 don't believe I suggested that one hacks it themself, it was difficult enough
for me.  I remember asking myself the very same
question at one time, when I wanted to write to the screen directly. I think I
ended up driving in that nail with my forehead. Well,
at one time Neil.e did not exist and I needed a solution of my own.  The
routines I indicated are an easily digestible example of
addressing the screen directly, not necessarily a solution (although they
comprise a limited one).  I simply condensed my own
experience, based on the question asked.  I believe I mentioned there were
better methods than mine in the original post.  It's
really up to the individual to decide what suits, direct screen writes or
virtual screens, and what library to use.

I do not use Neil in my own applications, even granted it's power, because I
have some special functions that might become tricky to
implement.  I do not know enough about Neil to incorporate them smoothly,
although that might change soon.

Anyway, to wind up I'm not knocking Neil in any way, in fact I think it is very
impressive and most capable.  I'm not disagreeing
with you either, Ralf, virtual screens and sprites are the meat in the sandwich,
but I didn't think that was what the original
question was about.

> > 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.

If both the librarys perform identical functions, then indeed it becomes
confusing to keep the inferior library hanging around.
More often this is not the case, simalar librarys each have their own merit. 
Once again, the choice is with the user as to what
suits best, or to make their own if none suit.

> > 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 ?

Example programs show what a library does, more often than not it is assumed you
already know why and don't really want to know
how.  For a beginner this can make for slow progress figuring out how to do
something that isn't exactly what the library was
written for.  If the simpler but more instructive librarys were tagged as
beginners librarys this process could be made easier.  The
more good relevant reference material one can find the easier it is to
understand and conquer a specific problem, no matter what the
functional quality of the example may be.

> 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)

 Hehe I do not have Eu for W as of yet.  This also will change soon.

Cheers all,
Nick

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

Search



Quick Links

User menu

Not signed in.

Misc Menu