Qbasicnews.com
freeBASIC (a 32-bit QB-syntax compatible compiler) preview.. - Printable Version

+- Qbasicnews.com (http://qbasicnews.com/newforum)
+-- Forum: General (http://qbasicnews.com/newforum/forum-6.html)
+--- Forum: General/Misc (http://qbasicnews.com/newforum/forum-18.html)
+--- Thread: freeBASIC (a 32-bit QB-syntax compatible compiler) preview.. (/thread-4948.html)

Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40


freeBASIC (a 32-bit QB-syntax compatible compiler) preview.. - ShadowWolf - 11-05-2004

i have to agree with most of the post so far incressing QB already larg run time would only limmit FB that's why Libs exist to extend the lang dynamicly.

the only run times that should be support are most of the orignal QB runtimes for backwards compatiblity.

just run the qb primative gfx's command though a wraper of some kind you most likely could writte a wraper for Peek and poke as well at least some of it i.e. where the program attamps to change the screen to 13h and where it attampts to write to vedio memorey.

well this is my meaningless opinion for what ever it worth Big Grin but in the end i could careless i'm just happy FB exists


freeBASIC (a 32-bit QB-syntax compatible compiler) preview.. - adosorken - 11-05-2004

Such things are so easily accomplished through the use of TinyPTC. Big Grin


freeBASIC (a 32-bit QB-syntax compatible compiler) preview.. - Z!re - 11-05-2004

Quote:you gotta be a really persistent bitch to finish a compiler (rtmlib etc).. that's not me, no sir Tongue
Source: http://forum.bad-logic.com/viewtopic.php?t=59


Hehe, I hope you're more of a persistent bitch now then =)


freeBASIC (a 32-bit QB-syntax compatible compiler) preview.. - v3cz0r - 11-05-2004

Heh, oh yeah, i'm sorta ;) Stills, ppl will have to help finishing the rtlib, i'm not going to add any of QB's GFX statements (but Stearling said he will do that..). Sound too, if nobody codes SOUND/PLAY/BEEP, we will have to live with Midi's, Mod's, Mp3's and such ;)

And sorry, but i don't want to add any new statement/intrinsic function, like for Mod/sound playing for example. That makes the runtime lib hard to write (and thus to debug and fix), porting to other OSes becomes complex, name clashes start to happen with old code and the documentation becomes tedious to write and to read, as it can get really huge.

With people porting/translating including files and using portable libs (if that matters), doing '$include: 'somelib.bi' and then calling the lib's routines would be the same as having them as intrinsic functions.. but then the responsibility of fixing its bugs would be of the lib's author, not mine ;)


About the IDE/Editor, i dunno, any with support for VB could be used, setup is not that hard, as most have support for M$'s error messages, that's the format FB reports errors.

Having debug support inside a custom-made IDE can be quite hard, as only GDB (GNU's debugger) can process the debug info that will be included on the exe's (stabs format, not coff). Dev-C++ seems to integrate GDB into the IDE, but i've no clue how to do that atm.. If we had something like that, it would be like tracing code in QB, would be great..


freeBASIC (a 32-bit QB-syntax compatible compiler) preview.. - barok - 11-05-2004

no qb gfx statements? Well, as long as SOMEONE puts them in, i'm happy. (so you better sterling, or i will...) Wink So long as i see PUT, Poke and Out, i'm satisfied.


freeBASIC (a 32-bit QB-syntax compatible compiler) preview.. - adosorken - 11-05-2004

Honestly speaking, it cannot be called 100% QB compatible without...well, everything represented. Big Grin I had implemented screenmode emulation in OBDS, so all the screenmodes that QB handles natively were working...some better than others but regardless...they worked. Big Grin I am hoping that whoever writes a wrapper for these will be able to also emulate these legacy modes, as there's a whole ton of software on the Internet that uses them, and it'd be really cool to see these old sources compiled and running with FB. Big Grin

I'll start on a proper editor for this on Saturday...tomorrow's swamped with work again, so that's out. Sad


freeBASIC (a 32-bit QB-syntax compatible compiler) preview.. - marzecTM - 11-05-2004

i guess implementing those legacy videomodes will be a pain in the ass. since i'm not involved in writing this crap i really don't care...

on the other hand: why would people need peek and poke (despite the fact that in a win32 environment they would be pretty useless)? why would anybody use put anymore? believe it or not but all those nifty c-libs like sdl and the like are so easy to handle, it would take you about 3 days if you are a newbie to get a sprite on the screen really. and from there on you'll never go back to the qbasic statements.

i have to acknowledge that some basic stuff like screen, pset, point, line, circle, etc. would be great for newbies to start of tough...

hm... maybe you're right and i suck hehe...

(v3c, get on irc the hell...)


freeBASIC (a 32-bit QB-syntax compatible compiler) preview.. - barok - 11-05-2004

because if you guys don't put in poke and peek then it won't be 100% qb compatible? Wink

There are lots of nifty things on the internet that use poke and peek extensively. (look at toshi's pure qb demo contest) If that's not reason enough i don't know what is. Wink it'd just be nice to have a win32 version of some programs that just so happen to use poke and peek.


freeBASIC (a 32-bit QB-syntax compatible compiler) preview.. - relsoft - 11-05-2004

Quote:You will be able to use Rellib if Rel write a Windows port Wink.


If anyone want to talk about the project, join the #badlogic irc channel at irc.efnet.net.. cyaz

Oh hell, why not!!! That would be the first thing I'd do when I get my hands on the actual compiler. :*). As a wrapper to DX/GL perhaps.

BTW, Inline asm? Needs it for a fast enough sampling stuff like water fx.


Barok: You can do poking and peeking with FB's pointers.

Like:

Say P is a pointer to a surface,

Calculate the offfset(linear) and dp a *P = color. Same as poke or c = *P same as peek. Easier and better.

Here's and example I made in C last night. Dos though but the only thing not portable are the calls to mem.h

http://quickhost.qbtk.com/download.php?id=311

And considering it can support OGL, I don't see the need to do low level stuff with FB unless you need something that GL does not support.


freeBASIC (a 32-bit QB-syntax compatible compiler) preview.. - marzecTM - 11-05-2004

Quote:because if you guys don't put in poke and peek then it won't be 100% qb compatible? Wink

There are lots of nifty things on the internet that use poke and peek extensively. (look at toshi's pure qb demo contest) If that's not reason enough i don't know what is. Wink it'd just be nice to have a win32 version of some programs that just so happen to use poke and peek.

i'd have to look at those demos, but i guess that the use of peek and poke there would not work in a win32 environment, cause of protected mode and other stuff related to the os. so i doubt that v3c will include those commands

def seg = &HA000
poke 320& * y + x, 4
def seg

won't work in win32. also the segment layout used in realmode is not valid for protected mode, so def seg would be a problem, since it allows to define the segment peek and poke will read/write from/to. in pm you only have one segment in userspace so... and with the introduction of pointers in FB i see no futher use for peek and poke