Some ideas

[Cyperium]

Thought I'd post this in a new post instead of creating a thread;

Concerning the DQBGet Sub:

Code:

dim b(1000)
screen 13
pset(2,2),13
pset(3,3),14
pset(5,5),15


'get (0,0)-(10,10),b(0)
dqbget 0,0,0,10,10,varseg(b(0)),varptr(b(0))

dqbput 0,100,100,varseg(b(0)),varptr(b(0))



SUB DQBPut (layer AS INTEGER, px AS INTEGER, py AS INTEGER, seg AS INTEGER, off AS LONG)
_dest layer
def seg=seg
sx=(peek(off)+peek(off+1)*256)\8
off=off+2
sy=peek(off)+peek(off+1)*256
off=off+2
for y=0 to sy-1
for x=0 to sx-1
c=peek(off)
off=off+1
pset(px+x,py+y),c
next
next
END SUB

SUB DQBGet (layer AS INTEGER, px AS INTEGER, py AS INTEGER,px2 AS INTEGER, py2 AS INTEGER, seg AS INTEGER, off AS LONG)
_dest layer
def seg=seg

widthe = 8* (px2-px)
height = py2-py

POKE off, 10 * 8     
POKE off+1, 0   
off = off +2

POKE off, 10   
POKE off+1, 0
off = off + 2

for dummyy = py to py2
for dummyx = px to px2
c=POINT(dummyx,dummyy)
POKE off, c
off = off + 1
next
next
END SUB

Is there a specific reason why the code doesn't work as it should?

I figured that since the size in width is less than one byte (10*8 bits = 80) then I wouldn't have to worry about the last byte since it would be zero.
Also, the size in height is less than one byte, so I set the last byte to zero there too.

I don't know how to extract the two bytes from the integer properly in order to put them into the memory position describing the width and height of the sprite. The sample is of course only a test to see if I have understood it correctly, which I haven't , so I guess the question is; how do I extract the two bytes from the integer?

[Galleon]

Code:

dim b(1000)
screen 13
pset(2,2),13
pset(3,3),14
pset(5,5),15


'get (0,0)-(10,10),b(0)
dqbget 0,0,0,10,10,varseg(b(0)),varptr(b(0))

dqbput 0,100,100,varseg(b(0)),varptr(b(0))



SUB DQBPut (layer AS INTEGER, px AS INTEGER, py AS INTEGER, seg AS INTEGER, off AS LONG)
_dest layer
def seg=seg
sx=(peek(off)+peek(off+1)*256)\8
off=off+2
sy=peek(off)+peek(off+1)*256
off=off+2
for y=0 to sy-1
for x=0 to sx-1
c=peek(off)
off=off+1
pset(px+x,py+y),c
next
next
END SUB

SUB DQBGet (layer AS INTEGER, px AS INTEGER, py AS INTEGER,px2 AS INTEGER, py2 AS INTEGER, seg AS INTEGER, off AS LONG)
_SOURCE layer '******POINT reads from the _SOURCE not _DEST surface********
def seg=seg

'ensure px,py is the top left corner (just thought I'd add this, it may not be necessary)
IF px>px2 THEN swap px,px2
IF py>py2 THEN swap py,py2

widthe = 8* (px2-px+1) '****(10,10)-(10,10) has a width of 1 pixel, so +1 to differences****
height = py2-py+1

POKE off, widthe and 255
POKE off+1, widthe \ 256
off = off +2

POKE off, height and 255
POKE off+1, height \ 256
off = off + 2

for dummyy = py to py2
for dummyx = px to px2
c=POINT(dummyx,dummyy)
POKE off, c
off = off + 1
next
next
END SUB

A few mistakes fixed here, now it works!

[Cyperium]

Thank you, those two subs were the most difficult ones of the whole library I think now it shouldn't take long to get the basic functions to work.

(there are over 130 functions in the DirectQB library, so I may not do them all myself, but since it will come with the source anyone can feel free to do more, I will only do what I consider useful and those that are easy or that I can find techniques to).

[Cyperium]

I just got my DirectQB game to work in qb64

It just goes a tad too fast (to say the least), so I'm working 24/7 on the DirectQB fps routine, also some colors seem wrong because DQB used a different palette so I'm going to work on that too.    (EDIT: the DirectQB fps routine is finished - with a few flaws, will be updated when qb64 v.084 is released)


After I fix the fps routine so that it works correctly and made the palette routine, I will create support for the DirectQB fonts that were used. Right now there are no fonts but only simple text.     (EDIT: turned out the fonts were easier than the palette so I did that first)

The DirectQB sound routines and the 3D routines will not be made any time soon, as I seldom used them in my own games (since the DQB sound wasn't any good (only 64 kb sized 8-bit files supported)) so I'll do them when I find the time and when the functions/subs I used for my games are completed.

Also, there are no support for joysticks or keypads yet.

The first version will be released when I have made palette routine (+some more probably).

-------Progress:
The fonts are now almost ready, but the styles will take longer to implement, I will simply update this post for changes in the progress, so check in to see if anything is new from time to time, take notice of the last edited date.

First release of DQB 2 QB64, but it is buggy, but should work for some games at least. My game I got working is released with it, but I forgot to add the data, so the data is available three posts from here, if you want to check it out.

[Cyperium]

Here is the link to the release, I will go on vacation so I am releasing it now, the IDE is working pretty well (in options you can disable the capitalisation of commands if you have large programs, since it will go slower).

If you don't want to use the IDE you can just open dqb2qb64.bas in QB64.

The CONST that has . (dots) in its variables have been remarked, in future versions of QB64 (like 0.84) you can remove those remarks as it supports dots in varible names.

dqb2qb64.bas currently has my game that I got working embedded, but you can just remove that part and add your own sourcecode and if it doesn't have any unsupported functions/subs then it will probably work. If it doesn't work then you can send me an e-mail to cyperium@hotmail.com

Known issues are:
The palette which I haven't included any functions for yet.
The fonts that are supported but to a limited degree.
The other functions and subs (there are >130 of them, so it's going to take a while to get them working)

However; I have included the most important subs/functions to get a ordinary game working, and if you start a game from scratch you won't have any problems with the palette, it's just that old games might have used a different palette or the palette set by DQBloadImage, so in these cases the colors might differ (but I'm working on that).

Here's a link to the release: DQB 2 QB64

[Galleon]

Can I have the data files from your game too? I'd love to see it in action!

[Cyperium]

Of course, don't know how I could forget

Here it is: http://www.geocities.com/cyperium/venture.zip

The game assumes the data files are in C:\BASIC\VENTURE\

But the path can be set to any directory by altering the variable holding the path, which is patte$

Note: the game does look better in original QB but only because the palette is wrong and because some functions aren't fully supported yet (but supported to a degree that it at least works ), you might notice that when you press CTRL you see something exploding in front of you, this is because the fireball is invisible due to DQBrPut (I think) which isn't fully implemented yet. Also, the text when you talk to people might be blurry, and this is probably because that styles for the font isn't fully implemented yet.

Note: In order to enhance appearence of the IDE you might want to choose File - Options and uncheck "Make valid statements uppercase on SPACE/ENTER/F5" respectivly or set the maximum number of lines (for uppercase checking) to a low number.

Second note: I noticed a bug that I don't have time to correct in the IDE, sometimes it doesn't find the .exe file produced by qb64, I will look onto this later, I think that running the game with F5 rather than the menu or button should work best for now.

[Galleon]

Brilliant.

The screen-shot you posted doesn't do it justice, this is not only a good engine but already a game with many interesting levels too. I was expecting a poor Mario clone but this has great potential. I downloaded dqb2qb64 & the venture files and did some very simple tweaking with the directory names to get it to run. Fyi I just ran dqb2qb64.bas and didn't test out the IDE. You were right, V0.84 can handle those constants with periods in their names.

I'll investigate the DQB subs/functions you've made in more detail later when I get the time.
Galleon

[Cyperium]

Thank you, it means much to me

I'm going away in an hour on vacation, so I can't reply anymore after this. Glad you enjoyed my game!

I'll be away for approx. two weeks. See you then!

[iamdenteddisk]

I go with Galleon on the creating subs and functions with the same handle as the original library's , that way you can "include them" and not "require them". If you guy's are remotly like me some day's I need the space and don't need "squaters" taking up the realestate. Other projects are all about functionality and not complexity..

Also that way "any source file" with some new functionality becomes a potential include and it isn't the old way where you had to buy one package to put sprite and another to playwav that where never compatable leaving you to stumble thumb through trying to make it work and leaving you with a lib that either didn't work or was illeagle to own because of modifying or copying hybrids of copyrighted materials.

I think I first understood this using asemblystudio8x for the ti calculators which was a cross asembler IDE using TASM

it include any text file for a include most folks library'd .h or .inc files which where equates to a tab file to share inturupts and the TASM allowed you to use the .tab or commands set file that allowed cross assembly for multiple processors/platforms..
which would be super if jumping win/Linux or 8,16,32,64,128bit..etc..too.

[Cyperium]

I go with Galleon on the creating subs and functions with the same handle as the original library's , that way you can "include them" and not "require them". If you guy's are remotly like me some day's I need the space and don't need "squaters" taking up the realestate. Other projects are all about functionality and not complexity..

Also that way "any source file" with some new functionality becomes a potential include and it isn't the old way where you had to buy one package to put sprite and another to playwav that where never compatable leaving you to stumble thumb through trying to make it work and leaving you with a lib that either didn't work or was illeagle to own because of modifying or copying hybrids of copyrighted materials.

I think I first understood this using asemblystudio8x for the ti calculators which was a cross asembler IDE using TASM

it include any text file for a include most folks library'd .h or .inc files which where equates to a tab file to share inturupts and the TASM allowed you to use the .tab or commands set file that allowed cross assembly for multiple processors/platforms..
which would be super if jumping win/Linux or 8,16,32,64,128bit..etc..too.

Yes, the subs and functions will have the same handles. Initially I thought that would be too complex for me, and thought of doing a translator instead, the problem was I had to do my own put/get routine (and I didn't know how that worked) but thankfully Galleon solved those problems for me and subsequently made me learn how to translate integers into bytes etc.

Putting all the functions and subs into a directqb.bi file will make it 100% compatible with the old qb when Galleon adds the $include metacommand, I just hope that the included .bi file can contain executable code and not only declarations.

[iamdenteddisk]

has there been any statment's about the includes being in binary format exclusivly?

I mean it's cool with me any way he chooses to do it,  I would think if the IDE would accept both compiled binary's and text.bas files you could write or even debug a flaw in your library's and it would help too if say your new function needed altered to become cmpatible with your existing lib's.

I know binary is faster but unless a disassembler is available once in that format your kinda stuck with it and with the rate of change in technology, Paying it forward is insurance . it seems if all libs where distributed in a text format then compiled pre final development or on demand, it would afford not only alteration and debug to libs but ensure QB64 to adapt to newer tech and multiple platforms. like the .tab files used with TASM.

lets see if I can make since of it here ,
.tab files contain equates to numonics or list of tokens,inturupt vector's using processor names like 6502.tab or TIz80.tab i386.tab x86.tab ...etc.. containing vector list.

example:
mov     Equ. ########
jmp      Equ. ########
cmp     Equ. ######## <what ever vector value like that

then .h and .inc files should contain the subroutines that make up your different functions that use the cpu/bios instructions in the .tab files
then at setup ,from the CD you bench test the system and O.S. to match the corect tab's to it and that way the .h & .inc and source code.bas files aswell as the IDE become universal. Never needing replacement but will accept upgrade to greater compatability.
Ofcorse it would be nice to also be able to include a picture/wav file to, that way you could work from outside media and only include its loader like jpg.h -just some ideas..

I read that QB64 birthed from qb4.5 and is now developed on QB64 witch compiles to C++ that converts to ASM then finaly ML for the machine. So Its kinda all inclusive allready, the irony is QB is 90% pascal compatible where C++ is pearl/java/html compatable and ASM is translated ML. thats all the important languages thus far..

that means you translate your english to near english basic which goes thrugh 5 total translations before the machine gets it and converts it to output in a microsecond. Also it means by default QB64 will probably accept most of them "if" the untranslatable instructions fall thrugh to the next translator in the chain.
 Heavy idea there..

[Cyperium]

The .bi files were never binary, it just contained the declarations of the binary functions of the .qlb file.

I think it would be easy to allow executable code in the .bi file while still allowing the declarations of the .qlb file (if needed).

I don't know exactly what files Galleon intended to be allowed as includes, or how complex he intends it to be, I guess we will have to wait to see interesting ideas anyway.

[Cyperium]

I thought you might want to know what's happening with DQB2QB64 as of now, I'm trying to fix some bugs that I have found, and until those bugs are fixed further improvements will have to wait (best to do full compatibility with what I have before adding new things), because of this the next release will be delayed.

For those interested one bug concern the DQBput subs and is nasty as it seems to apply only to some scenarios...have to try this one out further...

<I will keep updating progress in this post, for now on, as the earlier updates post is hard to find>

New updates will have a New! tag, so that you can find it easier!

Like this:

The IDE is now improved so that it almost never fails! The DirectQB library translation is on hold because of bugfixing.



New! - December 15

Fonts are fully working! (even styles of DQBprints), I'm now going to get on the Palette (the directqb library set a different palette upon initvga so that it differs from the original qb standard), also DQBsetPal is going to be implemented.