Qbasicnews.com
January 17, 2020, 06:55:50 PM *
Welcome, Guest. Please login or register.

Login with username, password and session length
News: Back to Qbasicnews.com | QB Online Help | FAQ | Chat | All Basic Code | QB Knowledge Base
 
   Home   Help Search Login Register  
Pages: 1 [2]
  Print  
Author Topic: QBW (QB editor for windows) v1.0  (Read 11275 times)
Frenkel
Member
*
Posts: 26



WWW
« Reply #15 on: July 12, 2004, 02:07:52 PM »

Quote from: "TheBigBasicQ"
Well, he should've mentioned that! :Huh: Files saved in QB format are stored as binary files. So windows editors such as notepad cant display them correctly.


I think that was pretty obvious, in a topic about QBW.

I can't open those files correctly in QBW.
Logged

roeten van Frenkel
Visit us at The Official S&F PROD. Homepage
TheBigBasicQ
*/-\*
*****
Posts: 4550



WWW
« Reply #16 on: July 12, 2004, 04:36:34 PM »

Sorry, but I am a bad reader. I am always in a hurry. So I tend to forget the reference of the writer :oops:
Logged
adosorken
*/-\*
*****
Posts: 3655



WWW
« Reply #17 on: July 12, 2004, 09:04:12 PM »

Quote from: "TheBigBasicQ"
@adosorken: when can we see something working? :bounce:

As soon as I finish screenmode emulation. At present, only SCREEN 1, 2, 9, and 13 are emulated. However, doing SCREEN 640,480 and such works (I've taken out the bpp setting, it will automatically use the highest available mode in fullscreen, and the current desktop setting in windowed). Also, I've decided against MASM32, as it was becoming way too complicated to pull off, and instead, I'm aiming for C source which should work in most any Windows-based C++ compiler. Right now it's targetted for MSVC++ (and why not...aside from Intel's compiler, MSVC++ is the fastest there is), but I'll clean it up later to conform to the standards. Cheesy
Logged

I'd knock on wood, but my desk is particle board.
DrV
Na_th_an
*****
Posts: 1553



WWW
« Reply #18 on: July 13, 2004, 10:02:03 AM »

@adosorken: I don't suppose one could POKE at A000:0 to write pixels with SCREEN 13... or is the segmented memory model  :barf: emulated too?
Logged
TheBigBasicQ
*/-\*
*****
Posts: 4550



WWW
« Reply #19 on: July 13, 2004, 11:45:45 AM »

I dont think so. Since this is a windows version of the QB compiler it will eliminate certain things until Nek wants to add emulated  support for that to =P.
Logged
Frobozz
Forum Regular
**
Posts: 145



WWW
« Reply #20 on: July 15, 2004, 01:13:28 AM »

Quote from: "DrV"
@adosorken: I don't suppose one could POKE at A000:0 to write pixels with SCREEN 13... or is the segmented memory model  :barf: emulated too?


I'd imagine the PSET he'd make would be faster than emulating a modification to a memory location.
Logged
TheBigBasicQ
*/-\*
*****
Posts: 4550



WWW
« Reply #21 on: July 15, 2004, 12:41:53 PM »

yep, imagine directX speeds against emulated memory read/write =P.
Logged
adosorken
*/-\*
*****
Posts: 3655



WWW
« Reply #22 on: July 15, 2004, 09:06:28 PM »

You're all correct...sorta. Cheesy Yes, POKEing to segment A000h with offsets 0-63999 will plot a pixel in the emulated 13h. Yes, PSET is slightly faster in that respect (since there's a couple of additional checks, but other than that, it functions the same basic way). BLOAD and BSAVE to load and save the contents of screen memory still function as normal, but their functions have been greatly reduced otherwise (you can use it to quickly load and save arrays, but since Windows has no segmented memory like DOS does, it's mostly useless to use anymore...that is my opinion and anyone is welcome to challenge it and give me a good reason to fully implement BLOAD and BSAVE).

The basic idea with OBDS is to be able to take working QB code and compile it for Windows. Nothing more...nothing less. I will try to provide wrappers for the many graphics libraries, but obviously .LIB/.QLB files will no longer function (their routines will be remapped to functions that already exist in OBDS's standard libraries). And of course, I've added new functions and capabilities to the language (PSETing in 1024x768x32bpp is pretty fun Wink). But the primary priority of OBDS is to replicate QB in the Windows environment, and that's what it will do FIRST before all the other bells and whistles.

(As a side note...I have no real intention of writing wrappers for QB sound libraries, as each one is too different to really deal with. There IS built-in support for many media formats, this is provided by both Bass.dll and FMOD [you can select which one you use; the functions are "intelligent" and wrap the right library].)
Logged

I'd knock on wood, but my desk is particle board.
relsoft
*/-\*
*****
Posts: 3927



WWW
« Reply #23 on: July 16, 2004, 03:47:03 AM »

Why not ditch all of the QB functions that deals with segmented memory models?  It would make coding easier.  Just a thought.
Logged

y smiley is 24 bit.


Genso's Junkyard:
http://rel.betterwebber.com/
adosorken
*/-\*
*****
Posts: 3655



WWW
« Reply #24 on: July 16, 2004, 08:57:38 AM »

I pretty much have...but in the interest of maintaining legacy code, some of it has to be left in. Like if someone has a game they wrote a few years ago, before the advent of the graphical libraries, they could just load it into OBDS and compile it without having to make a single change. The idea here is to not break all the QB source that's floating around out there (just some of it, hehe) but at the same time, try to transition people to a more improved version of their favorite language...one which will stand the test of time and operating systems.

For example: programs which work at the hardware level will require some software emulation. There's a way to use the I/O ports through 9x, but 9x is quickly losing ground in favor of NT, so it's questionable as to whether or not I'd want to include this method. Things like pure QB wav players will no longer work, since Windows doesn't allow direct access to the sound card (even in assembly, you have to invoke system functions for sound). There's some new sound functions, and I'm going to try to maintain the SOUND and PLAY functions (PLAY could become useful again, as I plan on giving it an option to use the MPU-401 at some point) so any games which use these commands won't be broken. But any new games written can take advantage of the new commands.
Logged

I'd knock on wood, but my desk is particle board.
TheBigBasicQ
*/-\*
*****
Posts: 4550



WWW
« Reply #25 on: July 16, 2004, 04:09:52 PM »

If I were you I would do away with all low level hardware access functions and provide a rich set of wrappers for various libraries Cheesy
Logged
adosorken
*/-\*
*****
Posts: 3655



WWW
« Reply #26 on: July 16, 2004, 09:23:20 PM »

Well, that's what I'm already doing for all the various graphical libraries out there. Cheesy

Code:
SCREEN 640,480
SETFONT default
PRINT "Yay! OBDS 0wnz m3!"
SETFONT "dumbfont.bmp", RGB(255,0,255)
PRINT "Custom bitmapped fonts are fun! ;)"
DO: LOOP WHILE INKEY$ = ""
END
Logged

I'd knock on wood, but my desk is particle board.
TheBigBasicQ
*/-\*
*****
Posts: 4550



WWW
« Reply #27 on: July 17, 2004, 06:03:57 AM »

w00t, I cant wait to try out my GUI =D. It uses the future.lib. I wonder how fast will it be Cheesy
Logged
Pages: 1 [2]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.21 | SMF © 2015, Simple Machines Valid XHTML 1.0! Valid CSS!