Generic Questions

[Guest_imported]

My questions are:
Can anyone lead me to a good UniVBE 5.1 library?
How do you use libraries?
How do you create libraries?
How do you do ModeX or better?
" the smallest memory screen dump (320x200, any format?
" use XMS, EMS and such?
Can anyone show me good SmartDRV tricks for QB?
Can anyone make a good .3DS loader (other than you! Gilgamesh021)?
Uh, I forgot the rest.
I have a 486DX2, EMM386, 3.5" drive, QB 4.5, VisualBasic ?.?, SmartDRV, UniVBE 5.1, Windows 3.1, DOS 5.0, and no CMOS
PS: can anyone make a QB CMOS backup?

 

[Nyaj2k1]

The best library around is called the Future.lib. It allows access to VESA modes (tested by me) up to 1600x1400x32 bit color. It lets you use EMS and XMS memory, not for data, but for quickly storing images of screen data and throwing screen data in XMS or EMS back to the screen.

It supports the GIF, and BMP image formats... and loads them faster then you would think possible. Screen paging, mouse support for SVGA and normal QB screen modes.

On top of all that, it has flawless support for playing WAV files in the background with one command-call access, as well as returning sound data so you can make cool visualizations and stuff...

It uses all standard VESA calls, so you don't even have to load a driver in DOS for 99% of all video cards. (Never had trouble... even on really old machines like 486...).

It comes with two versions on the library. One for QB45, and one for QB71. I personally like QB71 as the more powerful breed... It seems to have less memory problems then it's older counterpart when it comes to compilation, as well as overall speed is increased when using libraries.

To load a library, in the QuickBasic command line add the /l switch and use it as:

If you are using QB45:

QB.EXE /AH /L Future45

If you are using QB71:

QBX.EXE /AH /L Future71

This assumes that the Future45.qlb or Future71.qlb files are located in the same directory as the QB you are using. Go to this web address, scroll down the page and download "fl35.zip". I know they say the file size is in MB, but don't worry, that's just a typo. They mean KB. Here's the link to Future Softwares Library Download Page.

http://www.qb45.com/qbasic/modules.php?op=modload&name=Downloads&file=index&req=viewdownload&cid=11

After you download the file, extract it into your QB directory and run the included program "FLBUILD.EXE". Go through the process of selecting included options and creating the Future45.qlb or Future71.qlb.

After you are in the QB or QBX IDE, in the beginning of your code type the line:

rem $include:'future.bi'

This sets up all the Future.Lib commands and declares them for your use assuming you loaded the QLB file into the IDE on startup.

The Future.Lib is fully and comprehensively documented and comes with example programs for lots of different applications and commands.

 

[Guest_imported]

Wow, thanks. This lib rocks. Yo, one more question
you know Secret of mana, final fantasy 2 and 3, and mario kart? They use MODE 7 graphics. Can you or anyone figure it out? On a side note... Can anyone lend me PKZIPFIX.EXE?

 

[Nyaj2k1]

Glad to be of help. Any questions about the Future.Lib?

 

[Nyaj2k1]

Are you reffering to NES or SNES console programming, or am I confused? I'm not sure what you mean by MODE 7, and by best guess (by looking at the games you listed) is that you are talking about console programming...

 

[Nyaj2k1]

Here's PKZIPFIX.EXE:

http://home8.swipnet.se/~w-83211/files.htm

And (even though I'm not a console programmer) I think these docs on Mode 7 look pretty good to me.

http://pitel-lnx.uvis.fnt.hvu.nl/~drkfdr/http://darkfader.net/gba/files/Mode 7 tutorial.txt

Hope this helps.

 

[Guest_imported]

Thanks for the links, It will take me a while to figure out any of the MODE 7 stuff, but it should be interesting. If I ever get a little time off work I'll whip something up and send it to you (or to wherever you want to download it from,it may take a while because I'm not that good with QB yet)

Do you know a fast way to scale (maybe even rotate) sprites grabbed with the GET command, My attempt was so slow it was pathetic, using DATA statement and FOR...NEXT placing the scale amount of pixels per data point. (like placing the same color 4 times in a square instead of once)
------------------
Programming will take a while because I accidentally used BCOM45.LIB and BRUN45.LIB (or whatever they are called) as list files and I am looking for my install disks. LOL oh well.

 

[Nyaj2k1]

Look at the Future.Lib's HTML documentation... the EMSRotate command should to a pretty good job.

 

[Nyaj2k1]

You do realize that none of that MODE 7 stuff is QBasic, right?

 

[Guest_imported]

Console MODE 7 gfx are not, by default, possible in qbasic. However, using scaling, rotating and contast modification, I may be able to ,some day , find a way to emulate this in qbasic. I am a 3d MAX movie maker, not a programmer, I am only doing this for the credits. But hey, it is kinda fun.

 

[Nyaj2k1]

Why emulate? If you are going to go to all the trouble to emulate Mode 7, why not just use rotating and scaling in QB itself?

 

[logiclrd]

Rotating and scaling are fairly easy to do, as long as you have a firm grasp on linear interpolation. The idea is basically that you simultaneously draw two lines. One line, across the screen, is exactly horizontal (all on the same Y coordinate). The other line traces across the sprite at a different speed and/or angle, which is what achieves the rotation. The trick, then, is to determine what exactly these two lines are.

The basic idea is to store a start and end coordinate for each row on the screen. Many of them will not be used, so you need to initialize them to a value that will be readily identifiable when you go to draw to the screen (perhaps set end X to the left edge of the screen and start X to the right edge, and then check if startX < endX before proceeding for each scan).

Then, you need to apply some trigonometry to get the screen coordinates of each of the 4 corner points of the sprite. This is a fairly short & simple bit of code to write, but if you're not familiar with trigonometry, it can be a daunting task. So, I'll just give it to you:
[tt]
TYPE pt
x AS INTEGER
y AS INTEGER
END TYPE

DIM screenPt(1 TO 4) AS pt

spriteCenterX# = 150 'this can change
spriteCenterY# = 150 'so can this
spriteScaleFactor# = 1 'and this
spriteSize% = 32 'and this
spriteAngle# = Deg2Rad#(37) 'and this
spriteAspect# = 0.8333333# 'this is correct for SCREENs 1, 7 and 13

'Now the actual calculations:
angle# = spriteAngle# + Deg2Rad#(45)
rayLength# = spriteSize% * spriteScaleFactor# * SQR(2) / 2
FOR i% = 1 TO 4
screenPt(i%).x = spriteCenterX# + rayLength# * COS(angle#)
screenPt(i%).y = spriteCenterY# - rayLength# * SIN(angle#) * spriteAspect#

angle# = angle# + 1.570796# 'this is 90 degrees in radians
NEXT i%

FUNCTION Deg2Rad#(degrees#)
Deg2Rad# = degrees# / 57.295779#
END FUNCTION
[/tt]

The help file has a section on calculating the correct aspect ratio for different screen modes, but I can't remember exactly how to get to it Dig around.

Anyway, now that you have these 4 points, you need to use linear interpolation to connect them. Find the topmost point, and then use some simple facts to draw the right lines into the right endpoints in the previously mentioned scanline buffer.

The output from the code above is in anticlockwise order, so you know that if point 4 is the topmost point, then point 1 will be the one on the left and vertically in the middle and point 3 will be the one on the right and vertically in the middle. Point 2 will be at the bottom. In general, add 1 to the topmost index and wrap around if necessary to get the left point, and subtract 1 & wrap around if necessary to get the right point.

Once you have which lines to draw all sorted out, you then need to use interpolation to place them onto the scanline buffer. Doing this, you will also need to associate each endpoint with the corresponding coordinate in the sprite. I recommend you use better than integer precision to store these coordinates, otherwise you will get jagged edges in the visual result.

Anyway, once you have a list of horizontal lines to draw, along with the starting and ending sprite coordinates, you then apply linear interpolation to each scanline in turn, which tells you what sprite pixel to put onto each screen pixel. This is the simplest of scaling & rotating algorithms, so do not expect stellar results If you scale up, you will get square sprite pixels, and if you scale down, you will get sparkling (like walls very far away in Doom). It requires obscenely more processing to eliminate these, especially in a video mode with palettized colour, so I recommend you just live with it It will be a more authentic replica of old console systems anyway.

If you've gotten to this point and understand everything except what exactly linear interpolation is, let me know, and I'll write up an explanation of it for you.

 

[Nyaj2k1]

My point exactly. LogicLRD, you must eather be a very fast typest, or you have to much time on your hands.