Re: Graphics mode 257 memory address(es)
- Posted by Nick <metcalfn at ALPHALINK.COM.AU> Apr 07, 1999
- 495 views
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