FBXL Social

James@ncot.uk james@social.ncot.uk

https://youtu.be/Cr5MjFWq8Ds

CONFIG.SYS: LOADHIGH loadhigh@bitbang.social

@james This is great! I've made two "cracktros" myself "recently" (*ahem* in the past 2 years) and it wasn't always easy to find useful examples. Mode X was especially a hoot to figure out.

All the documentation was there, plenty of old books can be found on Archive.org, but those are about using VGA for normal programs and games.

Other than that it was looking at a lot of uncommented code, so it's great to see the actual, non-standard effects being explained here.

sj_zero sj_zero
My old QB RPG engine ran in modeX 320x240. Graphically one of the most advanced qbrpg engines, it had particle rain effects and shadows and transparent text boxes, a long with pixel*pixel movement and scrolling. Getting that to work on a 486 or a Pentium meant figuring out how to draw most of the graphics in 4 passes, one for each graphics plane, and to get the number of multiplies down by a factor of a million (normally you do a multiply, a divide, and a remainder operation for each pixel which was too much on those old machines)

And if I got any details wrong, it's been 20 years...

https://fbxl.net/oma/qfak/index.html

(Has the QB version and the windows FB version)
replies
1
announces
0
likes
0

CONFIG.SYS: LOADHIGH loadhigh@bitbang.social

@sj_zero @james That's impressive, all in pure QBasic?

Because I've seen QB game libraries that were actually compiled C/ASM libraries to speed things up, with a QB interface.

edit: playing it now. It does require some cycles on DOSBox so I guess it is indeed pure QB, but the scrolling is very smooth.

edit 2: the wavy effect of the water is cool

sj_zero sj_zero
The source file is included, the drawall routine does it all as I recall. Definitely did the graphics in pure QB, with all the slowness that entails.

The only thing that might be assembly is the key handler. I really don't remember at this point, because I remember spending some time on an assembly key handler, but I also remember spending some time on a pure QB key handler. There was no native multikey routine so you had to poll the keyboard interrupt directly. I think an assembler keyboard routine would use interrupts to catch every key press and unpress whereas a QB routine has to poll the keyboard and is limited by the execution rate of the main game loop.

I guess, also the music. After Windows 2000 was released, any conception of using MS-DOS for music went out the window, so I think the dos version has a little visual basic program that looks for commands in a file in the root directory of the game, and then either plays or stops playing the music based on the commands in the file.