gfxlib test release

DrV · Post by **DrV** » Jun 19, 2005 6:36

This one goes out to all those stubborn old 'DOS-is-not dead' types... :)

Download fbdostst.zip

Only 320x200x8 and 320x240x8 modes are available; however, the examples in that archive should work correctly on essentially any hardware/software that can run other DOS FreeBASIC programs. Only a VGA is required. If a version 2.0+ CuteMouse driver is installed and a wheel mouse connected, mouse wheel information will be available in examples/gfx/input.bas.

If anyone could try running these examples and post here with your results, that would be great.

Note that this code isn't a 'final product' by any means; there are still many unfinished pieces. For example, the keyboard LEDs are not updated under real DOS (WinXP seems to do it for me, evil...); not every piece of memory accessed by interrupt handlers is locked into physical memory, so if something gets paged out, a page fault could occur during a handler, crashing the system - make sure you have enough physical RAM, or turn off virtual memory on your DPMI host; the list goes on...

On plain DOS, you'll need a DPMI host - CWSDPMI (http://clio.rice.edu/cwsdpmi/) will do the trick (it's installed by default with FreeDOS, and you won't need it under Windows, which provides DPMI).

The source is in the CVS; I'll be starting on VESA SVGA support if no major bug reports come in after this release.

EDIT: oops, looks like I messed up the wheel mouse code somewhere - the wheel value should still change with CuteMouse 2.0+ driver and wheel mouse, but incorrect values are displayed. I'll fix it later, gotta go to bed now, it's almost 2 am (guess I should test on 'real' DOS more often :).

dumbledore · Post by **dumbledore** » Jun 19, 2005 6:52

cool!

Post by **v1ctor** » Jun 19, 2005 7:48

Pretty cool, all tests worked just fine here, under XP.

With enough docs and stability i wonder if FreeDOS would include FB (stripped, ie: no external libs) in its distro.. maybe someone could tweak FreeDOS' edit.com and make a qbasic-ish editor.. welcome back to 1989! ;)

relsoft · Post by **relsoft** » Jun 19, 2005 7:58

Can you compile space impakto with it?

MystikShadows · Post by **MystikShadows** » Jun 19, 2005 9:46

So far so good DrV :-).

Those examples compiled fine and I didn't get a problem running them afterwards either. So far so very good :-). Awesome work :-)

jdebord · Post by **jdebord** » Jun 19, 2005 14:47

Tested on a PII MMX in plain DOS mode.

All programs worked. In the INPUT program I got the results of a QWERTY keyboard while I have an AZERTY keyboard.

Huge executables (~ 100 k), but could be reduced to about 50 k with UPX.

I could compile all the graphic modules of my FBMath library, except one which uses SCREENINFO.

DrV · Post by **DrV** » Jun 19, 2005 15:36

Thanks, y'all. :)

relsoft wrote:Can you compile space impakto with it?

I haven't tried it; where could I get the source?

jdebord wrote:I could compile all the graphic modules of my FBMath library, except one which uses SCREENINFO.

Can you compile the SCREENINFO one with the latest CVS win32 build, or is that a DOS-specific problem?

On the AZERTY keyboard issue... I'm hooking the keyboard interrupt, so the returned keys are based on the scan code returned by the keyboard. If you want to write a keymapping system... ;)

And yes, the executables are rather large, but so is anything compiled with DJGPP...

I don't know if the FreeDOS people will include it; they seem to want to keep pre-386 compatability, ugh... :) You never know, though.

smagin · Post by **smagin** » Jun 19, 2005 18:12

1) I've compiled Wetspot successfully, only NUMPAD seems not to work. Under plain system the program runs much faster.

2) MarioQB - SCREENSYNC is not functioning at all. After I've added this instead:

Code: Select all

asm
        mov dx,&h3DA
    l1:
        in al, dx
        and al,8
        jnz l1
    l2:
        in al, dx
        and al,8
        jz  l2

end asm

everything worked fine except some occasional slowdowns & gfx pixel rubbish (?! maybe program's own glitches, dunno).

3) input.bas Mouse cursor while moving left-right sometimes gets distorted a la "swapped word".

Adigun A. Polack · Post by **Adigun A. Polack** » Jun 19, 2005 18:34

DrV, I have just tried your new “GFXlib 2”-based test release for FB-DOS, and, in the two 8-bit color graphics resolutions — 320x200 and 320x240 — it is just about *every* bit as good as the Windows version of it so far (even MultiKey works excellent, too!)!! (^-^)// And, guess what, I have even successfully converted the original first-ever FB palette lib (called “The New FreeBASIC 8-Bit Palette Machine”) to be compatible with your new test release, too. And hey, I have tested that as well, and all works almost as fully good as the Windows original, with just a few bugs that need to be ironed out in the DOS conversion of the lib for FB. If all goes well there, I could very well be releasing the DOS version of my lib indeed. :D !

And also, the test release of yours works excellent with at least about any program that was originally made using just GFXlib 2 as the only one library for FB to use! I am really proud of you, my man DrV!! d=^_^=b

And Rel, I have tried to compile your Space Impakto demo just this afternoon using this FB-DOS test version here, and it caused some *major* ASM-based errors. :-( Apparently, man, the reason why here is because the ASM in the original demo is entirely Windows-specific. You might want to try changing all of the ASM code in your demo to make it DOS-specific. ;-) ! If you can remember the original ASM from the QB version of RelLib (and I believe that you do!), then hey, I am sure that you can accomplish this as well, my man! That way, it should hopefully fit the DOS version of your awesome FB demo. Just give it a whirl and see what happens. ^-^

Thanks a lot, DrV and Rel, and it is an honor to be speaking with the both of you in these official FB forums. :D

DrV · Post by **DrV** » Jun 19, 2005 20:25

Argh, yeah, I didn't code the ScreenSync correctly... blame DJGPP's libc for not having a WAIT like QB. ;)

And yes, the *Lock keys don't do anything except set the relevant MULTIKEY keys when pressed; that will be fixed eventually, but it's not high on the list right now... stability and high-res modes come first. :)

AAP, glad to hear that the Palette Machine is working well.

I'm wondering about the Space Impakto ASM errors, though - there shouldn't be anything Windows-specific in the inline assembly; if you could post a link to the source, I'll take a look.
[/quote]

jdebord · Post by **jdebord** » Jun 20, 2005 7:04

DrV wrote:
jdebord wrote:I could compile all the graphic modules of my FBMath library, except one which uses SCREENINFO.
Can you compile the SCREENINFO one with the latest CVS win32 build, or is that a DOS-specific problem?

It compiled with FB 0.13b under Windows. I have not tested the new versions.

My program uses a slightly modified version of the example given in the GfxLib documentation. Suspecting an error of mine, I checked the original example:

Code: Select all

TYPE SCREENINFOTYPE
	driver_name AS STRING
	w AS INTEGER
	h AS INTEGER
	depth AS INTEGER
	pitch AS INTEGER
	bpp AS INTEGER
	mask_color AS INTEGER
	num_pages AS INTEGER
	flags AS INTEGER
END TYPE

DIM info AS SCREENINFOTYPE PTR
SCREEN 15, 32
' Obtain info about current mode
info = SCREENINFO
PRINT STR$(info->w) + "x" + STR$(info->h) + "x" + STR$(info->depth);
PRINT " using " + info->driver_name + " driver"
SLEEP

But I still obtain the same error (Error 18: Syntax error) in the line which contains SCREENINFO.

DrV · Post by **DrV** » Jun 20, 2005 13:08

The syntax for SCREENINFO has changed recently; see lillo's post ( http://www.freebasic.net/forum/viewtopic.php?t=53 ).

jdebord · Post by **jdebord** » Jun 20, 2005 15:29

DrV wrote:The syntax for SCREENINFO has changed recently; see lillo's post ( http://www.freebasic.net/forum/viewtopic.php?t=53 ).

Oops, sorry! I had completely overlooked this... Now it works!

Thank you very much for this excellent library!

Adigun A. Polack · Post by **Adigun A. Polack** » Jun 20, 2005 16:46

DrV, if you want the original sources to the demo you are talking about, they are included for you in this following download:

• Space Impakto Demo (includes all .BAS and .BI source codes for FB!)

Now, what I’d do here is to extract the contents of the presented file into your FB-DOS directory, delete the two included .EXE files (“space_impakto.exe” and “space_impakto_debug.exe”), and then place all of the included .BI source codes in the “inc” directory of the main one where FB-DOS is, you read me here? ;) Next, you can check the ASM codes of the .BI files to see what could be wrong with the conversion to FB-DOS format. We are getting to the bottom of this, believe me. (p_^)

As well, man, the file “fbgfx.bi” is also required for that demo, and it is available for download right here. Just wanted to make sure I give you all that you need here, okay now? ^_^ !

Once again, I thank you so much, DrV. Be catching you later! :D

DrV · Post by **DrV** » Jun 20, 2005 17:21

Hmm, after changing the SCREENINFO use to the new syntax, it compiled and ran cleanly for me (way too fast, though, because my vsync routine is still broken :). Which errors in particular are you getting? I just put the files in the places you said and then executed an 'fbc-dos space_impakto.bas'.

I changed space_impakto_level.bi to use this code (for new SCREENINFO syntax):

Code: Select all

dim screen_w as integer, screen_h as integer

'    dim screen_info as  SCREENINFOTYPE ptr
'    screen_info = SCREENINFO

screeninfo screen_w, screen_h

	with lvl
		.m_screen_w              = screen_w
		.m_screen_h				 = screen_h - 32

gfxlib test release

gfxlib test release

Here are my results of your test version now.

Here is something that you need, DrV! :D