gfxlib test release
gfxlib test release
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 :).
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 :).
-
- Posts: 680
- Joined: May 28, 2005 1:11
- Contact:
-
- Posts: 612
- Joined: Jun 15, 2005 13:22
- Location: Upstate NY
- Contact:
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.
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.
Thanks, y'all. :)
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.
I haven't tried it; where could I get the source?relsoft wrote:Can you compile space impakto with it?
Can you compile the SCREENINFO one with the latest CVS win32 build, or is that a DOS-specific problem?jdebord wrote:I could compile all the graphic modules of my FBMath library, except one which uses SCREENINFO.
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.
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:
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".
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
3) input.bas Mouse cursor while moving left-right sometimes gets distorted a la "swapped word".
-
- Posts: 232
- Joined: May 27, 2005 15:14
- Contact:
Here are my results of your test version now.
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
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
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]
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]
It compiled with FB 0.13b under Windows. I have not tested the new versions.DrV wrote:Can you compile the SCREENINFO one with the latest CVS win32 build, or is that a DOS-specific problem?jdebord wrote:I could compile all the graphic modules of my FBMath library, except one which uses SCREENINFO.
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
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!DrV wrote:The syntax for SCREENINFO has changed recently; see lillo's post ( http://www.freebasic.net/forum/viewtopic.php?t=53 ).
Thank you very much for this excellent library!
-
- Posts: 232
- Joined: May 27, 2005 15:14
- Contact:
Here is something that you need, DrV! :D
DrV, if you want the original sources to the demo you are talking about, they are included for you in this following download:
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
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
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):
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