phat code If it's not on fire, it's a software problem.
Main

Projects

Downloads

Articles

Links

Forum

 

View Message

Back to Messages
Optimus Sat Jun 8 2024 at 1:36 am
Back to basic with novel mindset but questions
 
 
Somehow I got into the mood to start doing something on quickbasic 4.5 on my old DOS Pentium PC. I am pretty hooked with it right now where I slowly build day after day a 3d engine, curious as I never did it before, I never did more than 3d dots in my old demos. It's going well, I have a big cube fitting the screen at 90fps on my Pentium, found ways to also make a nice backbuffer and fast enough copy and not just directly write to videoram as in my old demos.

Also, interesting with modern sensibilities, a bit reading of new tricks I didn't know like optimization techniques on QB I found on this site or others, or rewatching some old demos and looking at their code, how many things I didn't know back then. Also my own code, without even knowing these things, I see it now and shudder. Thought the effects Into The Fight demo were fast as it can but I made the plasmas twice as fast for example.

Anyway, let's got to the questions, so I learned the cool thing that you could get the Segment/Offset of a variable by VARSEG or VARPTR. I figure out you can use this in various ways like, my buffer is vram%(32001) that I can set the width height in first two values and then PUT on screen, which works pretty good as a backbuffer. And just use DEF SEG on the VARSEG and VARPTR to write pixels as bytes similar as I was doing to &HA000. Pretty neat and fast enough compared to old methods where I split screen in two arrays or used some other crap to get top bottom byte.

I see now many source codes people use a lot of VARSEG and VARPTR even for regular arrays. Possibly to handle them as byte arrays and reduce memory? My own demos just never used that. It's cool, but I see in some demos they do DEF SEG(var) all the time per pixel and that would possibly be slower.

Anyway to cut it short the question is, after they finish they do a plain DEF SEG which I read returns to basic segment pointer. I might have read you have to do this. But I never do it and I didn't have a problem. I kinda have a problem sometimes though but when inside a function I get a VARSEG from my vram%(2) pointer use it, then exit the function. At some point I thought I can move that outside in a global. But then problem started and only sometimes. Sometimes it runs, sometimes it crashes. Do I have to do also the pure DEF SEG after a DEF SEG(vram%(2)) or something? Is it unsafe? Why in my old demos I did DEF SEG = &HA000 all over the place and never return it back?

A second question, I look more at the editor. I noticed that you can build a tinier executable that requires BRUN45.EXE. But usually we build the self executable so that others won't require this one. But I noticed something. Building the BRUN45 requiring version always gives a bit more performance. Like from 75 to 82 fps. I tested with various codes. Why is that? Even if I prefer to give away the self contained EXE without requiring BRUN45, like most things were released like this at the time, why would I get a bit of performance boost with the other build?

p.s. Ok that was too big. Man, working on qbasic through modern approach, I see what I like now and don't like on the language now I am more into modern programming. It had some simplicity but a lot of things are annoying. I am trying to do some arithmetic stuff or other, I hit the signed short integer limit and avoid using long ints even if they are not that bad in speed. I wish for an unsigned. But compiling things and running outside will work of course. I also check now the generated assembly and learn a lot on what to avoid and what not. I see multiplies by powers of two are several shifts instead of one to accomodate for 8088 compatibility. But integer division I thought it would be shift, no it's division. So tables made sense. Multiplies with small powers of two like 2,4,8 maybe 16 would be preferable. Anyway..
 
 
 
 

Reply to this Message

Name
Subject
Message

No HTML is allowed, except for <code> <b> <i> <u> in the message only.
All URLs and email addresses will automatically be converted to hyperlinks.