• Print

Author Topic: Some ideas  (Read 9002 times)

Cyperium

  • Hero Member
  • *****
  • Posts: 3285
  • Knowledge is good, but understanding is better
    • Cyperium
    • Email
Some ideas
« on: May 15, 2009, 03:42:56 PM »
I have programmed in QB 4.5 for more than a decade and I still do, so QB64 comes like a gift from above.

I have made many games using the DirectQB library, I guess you aren't going to make a library compatible with QB64 of DirectQB, however, it would be nice if you implemented some of its functions as they are really useful.

What I would really like to see is layers, layers and more layers! I like layers very much.

DQBcopylayer, DQBcopytranslayer etc. but in a format that would suit you. This would help me make games, and also to convert my old games to QB64.

I know that DirectQB was very popular, and I think that layers contributed to that popularity because of its ease of use, so many users should have made games with it and thus be happy :)

PCOPY only sets the current and active page, I need something that copies one layer on top of another, with an optional transparent flag if I don't want to copy the transparent color (0 for example).

Also; (sorry) It would be nice if I could print or pset or put/get something directly to a page or layer, like PRINT [page,] "text" - since it is optional it wouldn't bother compatibility and the program would be more readable than having to put a PCOPY before every new page you want to add something to.

I know that this might be low-priority, and I don't mean for you to do it right away. I just need to know if you are interested.
« Last Edit: May 15, 2009, 03:58:33 PM by Cyperium »
Venture - New Prototype, QB64 Editor v1.95b (linux compatible, if you compile the source).

Galleon

  • Administrator
  • Hero Member
  • *****
  • Posts: 4664
  • QB Forever
    • Email
Re: Some ideas
« Reply #1 on: May 15, 2009, 07:33:42 PM »
You can already do all that in QB64. Here's an example program to prove it.

Code: [Select]
SCREEN 13

'note: lowest layer number will be at the bottom, possibly obsequered by other layers
const layers=5
'create (320x200x256col) layers
dim layer(1 to layers) as long
for i=1 to 5
layer(i)=_newimage(320,200,13) '13 means screen 13 compatible
next
'create a layer to build/combine the layers upon
dim tmplayer as long
tmplayer=_newimage(320,200,13)

do 'main loop

'draw comething on all 5 layers

_dest layer(1)
if bc<200 then bc=200
line(0,0)-(319,199),bc,bf 'a background coloured box
bc=bc+1:if bc>250 then bc=200

_dest layer(2)
line(10,10)-(310,20),4,bf 'a status bar kinda thingy
line(12,12)-(12+barlen,18),2,bf
barlen=barlen+1: if barlen>298 then barlen=0

_dest layer(3)
_printmode _keepbackground
color 1+rnd*254
locate rnd*20+1,rnd*18+1:print "Amazing![";n&&;"]" 'text at random locations
n&&=n&&+1
_printmode _fillbackground
locate rnd*20+1,1:print space$(40);

_dest layer(4)
pset (rnd*320,rnd*200),rnd*256 'random pixels appear & disappear
pset (rnd*320,rnd*200),0
pset (rnd*320,rnd*200),0

_dest layer(5)
circle (rnd*320,rnd*200),rnd*1000,1+rnd*254,,,1/1
if barlen=0 then cls

'combine layers
pcopy layer(1),tmplayer
for i=2 to layers
_dest layer(i)
_clearcolor 0
_putimage (0,0),layer(i),tmplayer
next
pcopy tmplayer,0

'This slows the program down to ~18 fps, otherwise it's a bit hard on the eyes!
'Comment out the following 4 lines for maximum speed.
do
t!=timer
loop until t!<>lasttime!
lasttime!=t!

loop until inkey$<>""

(http://www.qb64.net/screenshots/albums/userpics/10004/LAYERS.jpg)

Quote
something directly to a page or layer, like PRINT [page,] "text"
You'd need to use 2 commands for this:
_DEST page: PRINT "text"
Note that page is actually an image handle, it just happens that 0 and positive numbers link the video pages. A coincidence? I think not.
Quote
PRINT [page,] "text" - since it is optional it wouldn't bother compatibility
Actually you're wrong, but I'll let you think about why.
« Last Edit: May 15, 2009, 07:47:04 PM by Galleon »
Something old... Something new... Something borrowed... Something blue...

Cyperium

  • Hero Member
  • *****
  • Posts: 3285
  • Knowledge is good, but understanding is better
    • Cyperium
    • Email
Re: Some ideas
« Reply #2 on: May 16, 2009, 04:35:41 PM »
OK, thanks...and of course you are right about the compatibility issue, it would print the number and a tab then the text...

I'm going to test for myself if this does everything I want it to, but it seems fine from your example. If I find improvements I let you know.

Also, I guess it's ok with two commands to achieve it.

Also #2; THANK YOU.
« Last Edit: May 16, 2009, 04:40:14 PM by Cyperium »
Venture - New Prototype, QB64 Editor v1.95b (linux compatible, if you compile the source).

Galleon

  • Administrator
  • Hero Member
  • *****
  • Posts: 4664
  • QB Forever
    • Email
Re: Some ideas
« Reply #3 on: May 17, 2009, 01:10:19 AM »
It would be good to create a DirectQB compatible library to run source which used this library. However until QB64 supports joystick & is a little bit more developed it will not be a priority. Of course, not all programmers using DirectQB use all of its functions. It could well be possible write some QB64 subs/functions to simulate DirectQB commonly used functionality. DirectQB is an extensive library of over 30 functions and as such it would take a fair bit of work. As QB64 allows DEF SEG, VARSEG, VARPTR etc at least you'd be able to correctly read 16-bit offset data passed to DQB's functions. If you'd like to start on such a project I'd be glad to assist you.

Interesting stuff,
Galleon
Something old... Something new... Something borrowed... Something blue...

iamdenteddisk

  • Hero Member
  • *****
  • Posts: 2737
    • Email
Re: Some ideas
« Reply #4 on: May 19, 2009, 11:34:36 AM »
No,NO,NO,no library's Please!!!!!!!!!
ARG!!!

don't mess up a good thing, keep it all "pure code" with an inculde directive for outside modules then if you need a function you bought or wrote yourself, you can just $include it and not have to buy a library to use a function and it exclude use of another that suxx duck butter, please for god sake just don't.


Galleon

  • Administrator
  • Hero Member
  • *****
  • Posts: 4664
  • QB Forever
    • Email
Re: Some ideas
« Reply #5 on: May 19, 2009, 01:23:43 PM »
Quote
No,NO,NO,no library's Please!!!!!!!!!
ARG!!!

don't mess up a good thing, keep it all "pure code" with an inculde directive for outside modules then if you need a function you bought or wrote yourself, you can just $include it and not have to buy a library to use a function and it exclude use of another that suxx duck butter, please for god sake just don't.
That isn't a library, that's pure QB64 code, standard graphics commands. I challenge you to write what the above program performs in pure QBASIC code without using the QB64 specific commands! If all you want is QBASIC, DOSBOX and QBASIC.EXE will do the job for you, QB64's goal is 100% QBASIC compatibility + the ability to take advantage of the memory, sound, graphics, networking, printing, interfaces etc of modern computers as required.
Something old... Something new... Something borrowed... Something blue...

iamdenteddisk

  • Hero Member
  • *****
  • Posts: 2737
    • Email
Re: Some ideas
« Reply #6 on: May 19, 2009, 10:25:29 PM »
that is what I mean stick with using pure code.

My biggest and only hate for qb was I could only use it for character based stuff, untill I discovered the pure code method for inturupts in 4.5 known as "inturuptx" then it opened the world to me 16bit thought it was .

I would try to find libs that said they would work for inturupts and none ever did and the libs that would work would give you a few usefull functions and lack others but they wouldn't be compatible with others so it was as if you had to relearn qb again and again to write the next program. and I never got the call absolute to work at all.

but with inturuptx it was a sample file hosted on petes I think that enabled mouse, I would rename and modify a copy of it into an entire Godgame like AOE in a few hours I could do about anything with it still to this day I keep a copy of it I modified into a mouse handler that I could use to dump inturupts and write asm as if it where built into QB it was simple and had all of it's complexitys setup into like 3-4 subs so there was maybe 20 lines of the program then my main program and the rest would be nestled in subs

 It so simplified things man, I would be willing to pay top bucks for the ability to have that simplicity in a 64bit QB. From what I have seen of sample code that is where it is heading and my last post there was just to speak-up in hopes that the good stuff not be bumped off and left to third party library's..

From what I have seen thus far, you have what qb-er's worldwide have craved for 20 years now. Atleast me anyway, I give you 4 thumbs up all the way, Now I am dieing to see how we do pure code inturupts and asm in code. I wish I could atach a sample source text of what I mean but don't want to clutter the forum. tell me if I can post that or where to send it as text and I will, I think the world would love you program even more if it was a simple as this..
  So Far ,Good work and keep goin I will keep watching and if it fits the bill in final release I want it for sure.
 

Cyperium

  • Hero Member
  • *****
  • Posts: 3285
  • Knowledge is good, but understanding is better
    • Cyperium
    • Email
Re: Some ideas
« Reply #7 on: May 27, 2009, 10:16:57 AM »
Quote from: Galleon on May 17, 2009, 01:10:19 AM
It would be good to create a DirectQB compatible library to run source which used this library. However until QB64 supports joystick & is a little bit more developed it will not be a priority. Of course, not all programmers using DirectQB use all of its functions. It could well be possible write some QB64 subs/functions to simulate DirectQB commonly used functionality. DirectQB is an extensive library of over 30 functions and as such it would take a fair bit of work. As QB64 allows DEF SEG, VARSEG, VARPTR etc at least you'd be able to correctly read 16-bit offset data passed to DQB's functions. If you'd like to start on such a project I'd be glad to assist you.

Interesting stuff,
Galleon
I'm not that good at programming libraries, I was thinking of creating a program that "translates" or rather; "simulates" most of the functions of DirectQB into QB64 compatible commands, so that if you had made a game in QB with DirectQB then you could just open the translation program to turn it into QB64 commands and it will (hopefully) work.

It will be fun to get my DirectQB games to function in QB64 since I can also add sound and probably it will perform better since QB64 is faster.

Of course, when (and if) I make such a program, I will make it available to all.

If someone makes an actual 64-bit copy of DirectQB that is compatible with QB64 I would be more than happy though :) (needless to say) hehe...

« Last Edit: May 27, 2009, 10:21:00 AM by Cyperium »
Venture - New Prototype, QB64 Editor v1.95b (linux compatible, if you compile the source).

Cyperium

  • Hero Member
  • *****
  • Posts: 3285
  • Knowledge is good, but understanding is better
    • Cyperium
    • Email
Re: Some ideas
« Reply #8 on: May 27, 2009, 10:25:56 AM »
Quote from: iamdenteddisk on May 19, 2009, 11:34:36 AM
No,NO,NO,no library's Please!!!!!!!!!
ARG!!!

don't mess up a good thing, keep it all "pure code" with an inculde directive for outside modules then if you need a function you bought or wrote yourself, you can just $include it and not have to buy a library to use a function and it exclude use of another that suxx duck butter, please for god sake just don't.


If you want to keep it all "pure code" then that is up to you, but remember that there are thousands of users that used DirectQB and other libraries (future.lib for example) that probably have many games that they can't play on modern computers and can't distribute, for them (and me) it would be very nice if QB64 supports them. As with QB 4.5 you would of course still be able to program "pure code"!

This isn't very high priority so I guess it will take a while, but I will try to make a translation program at least so that we are able to convert DirectQB games and programs into QB64 compatible code.
Venture - New Prototype, QB64 Editor v1.95b (linux compatible, if you compile the source).

Clippy

  • Hero Member
  • *****
  • Posts: 16431
  • I LOVE π = 4 * ATN(1)    Use the QB64 WIKI >>>
    • Pete's Qbasic Site
    • Email
Re: Some ideas
« Reply #9 on: May 27, 2009, 11:10:28 AM »
That sounds like a GOOD idea! Galleon can use some help if you can find a way.

Ted
QB64 WIKI: Main Page
Download Q-Basics Code Demo: Q-Basics.zip
Download QB64 BAT, IconAdder and VBS shortcuts: QB64BAT.zip
Download QB64 DLL files in a ZIP: Program64.zip

Cyperium

  • Hero Member
  • *****
  • Posts: 3285
  • Knowledge is good, but understanding is better
    • Cyperium
    • Email
Re: Some ideas
« Reply #10 on: May 28, 2009, 09:30:06 AM »
Sure, it may take a while though, but the simpler functions should be easy...(but things are always easy in imagination, the problems will probably become obvious when I start, but I have much experience in error-searching and solutions).

I take inspiration from Galleon on this, where I can release more and more able translators.

The first release will handle layers (as this seems easiest as there are nice ways of doing those in QB64) and some other basic stuff (like simply removing $include:'directqb.bi', handle dqbinit with the respective layers information etc.).

Needless to say this will only work on the source .BAS files, and standard text .BAS sources. Not actual .exe programs and not .BAS files which are "encoded" with the QuickBasic binary format. But when my program is fed with such a program it will tell the user to save the .BAS file as plain text, then to load it with the program again. A bit of effort on the user that isn't too much I think. Of course it may happen that in the future my translation program will handle even QuickBasics binary format, but not in any time soon - and it will never handle .exe files :)

My program will be called (as far as I know now) "dqb2qb64" and I hope I can post it on these forums, or I can post a link to it.

I'm currently collecting ideas on how to achieve it, and I already have plenty so don't be surprised if it turns up soon!

Also, if I find anything in the process of translation that can be nice to have implemented in QB64 I will let you know.

EDIT: progress so far is that dqbinit and dqbinitvga is supported, also dqbcopylayer. I haven't yet decided on how I should build the translation program so there will not be any versions out there yet. I just wanted to show that I'm serious about this and that I will keep working on it, even if you don't hear from me. When any version comes out, I'll tell you on this forum.
« Last Edit: May 28, 2009, 04:42:42 PM by Cyperium »
Venture - New Prototype, QB64 Editor v1.95b (linux compatible, if you compile the source).

Galleon

  • Administrator
  • Hero Member
  • *****
  • Posts: 4664
  • QB Forever
    • Email
Re: Some ideas
« Reply #11 on: May 29, 2009, 03:41:55 PM »
Quote
EDIT: progress so far is that dqbinit and dqbinitvga is supported, also dqbcopylayer. I haven't yet decided on how I should build the translation program so there will not be any versions out there yet. I just wanted to show that I'm serious about this and that I will keep working on it, even if you don't hear from me. When any version comes out, I'll tell you on this forum.
I'd be happy to support you with this project. At this early stage I'd like to raise what could be a serious problem with your strategy, that being writing a program to convert QBASIC programs using DQB into QB64 programs. The 'conversion' may seem simple on the surface but it can become near impossible in more complex programs. A much better strategy imo would be to simply create subs/functions with the same names as those used by DQB which perform the same actions. Later on, those subs can be put into a library. If there's a reason you think this cannot be done please let me know.
Something old... Something new... Something borrowed... Something blue...

Cyperium

  • Hero Member
  • *****
  • Posts: 3285
  • Knowledge is good, but understanding is better
    • Cyperium
    • Email
Re: Some ideas
« Reply #12 on: May 29, 2009, 06:32:19 PM »
Quote from: Galleon on May 29, 2009, 03:41:55 PM
Quote
EDIT: progress so far is that dqbinit and dqbinitvga is supported, also dqbcopylayer. I haven't yet decided on how I should build the translation program so there will not be any versions out there yet. I just wanted to show that I'm serious about this and that I will keep working on it, even if you don't hear from me. When any version comes out, I'll tell you on this forum.
I'd be happy to support you with this project. At this early stage I'd like to raise what could be a serious problem with your strategy, that being writing a program to convert QBASIC programs using DQB into QB64 programs. The 'conversion' may seem simple on the surface but it can become near impossible in more complex programs. A much better strategy imo would be to simply create subs/functions with the same names as those used by DQB which perform the same actions. Later on, those subs can be put into a library. If there's a reason you think this cannot be done please let me know.
Yes, I have thought of the exact same thing, I can think of no special reason why that wouldn't work.

I have one problem though, the DQBPut and DQBGet uses VARSEG and VARPTR to refer to the variables address that the image should be stored in, how could I use the ordinary PUT and GET with this in order for them to use the variable?

A ordinary DQBPut statement would be for example:
DQBPut layer, x, y, VARSEG(object(0)), VARPTR(object(0))

Could PUT and GET be used in that way? Perhaps a translation of only these special cases would do?

In that case the above sub would be translated to:
DQBPut layer, x, y, object()

(remove VARSEG and VARPTR and the zeros, also we won't need the redundant last argument)

I have tried this and it works! So I guess that it will be a combination of both a translation (so that it will work correctly with the QB64 statements) and a series of functions to be included in the file.

I guess this would be a valid compromise :)

Hmm...I guess that object() would have to be dimmed to work with any possible size that the user could want...

I will have to think this over a bit since I discovered a potential problem with the DQBGet sub...

EDIT: Thought it over and it was no problem :) haha, I like this :)

EDIT again: There is one problem though, and it is that you won't be able to get/put many objects in the same variable, one object could be stored at a different position in the variable so I need to find a way to leave the zeros or the index alone without error)

EDIT yet again: I guess the best way would be to translate the sub so that a position argument is passed as well, depending on the index.

It would then look like this:
DQBPut layer, x, y, object(), index

But then it wouldn't allow for multidimensional arrays....like object(0,0,0)...which it should...the best way would then be to make three different subs (so that it can at least be dimensioned to the third level) with each dimension, it would put a limit at three dimensions, but I guess that if a user were really desperate to have more than that, he could easily manage to change or add another sub. At least it covers the typical needs.

As a tip for enhancement it would be nice if we had bracketed arguments to be passed to subs and functions, that don't need to be included for the function to work.

Example;
SUB DQBPut (layer,x,y,object(),index[,index][,index])

...or something along those lines. Would it be consistent with the BASIC philosophy? I think so, and I have wanted it for years :)
« Last Edit: May 29, 2009, 07:07:10 PM by Cyperium »
Venture - New Prototype, QB64 Editor v1.95b (linux compatible, if you compile the source).

Galleon

  • Administrator
  • Hero Member
  • *****
  • Posts: 4664
  • QB Forever
    • Email
Re: Some ideas
« Reply #13 on: May 29, 2009, 11:01:47 PM »
Remember that VARSEG & VARPTR work in QB64!
If they aren't working for you, it's because of a glitch in V0.83 but I think that only related to VARPTR/VARSEG of user defined types. So just pass those values to a sub and use them using the standard DEF SEG, PEEK & POKE. What your program chooses to store at that location would depend on the level of compatibility you wish to provide. I'm unfamiliar what DQBPut expects to be there, but I'm guessing it's the standard [X*8],[Y],[pixeldata...] that QB uses to store its GET/PUT data.

For example:
Code: [Select]
screen 13

line(0,0)-(319,199),4,bf 'a big red screen!
dim b(10000) as integer
get (50,50)-(100,100),b(0) 'get the red stuff!
cls

line(0,0)-(319,199),1,bf 'a big blue screen!
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
Something old... Something new... Something borrowed... Something blue...

Cyperium

  • Hero Member
  • *****
  • Posts: 3285
  • Knowledge is good, but understanding is better
    • Cyperium
    • Email
Re: Some ideas
« Reply #14 on: June 01, 2009, 03:36:22 PM »
Quote from: Galleon on May 29, 2009, 11:01:47 PM
Remember that VARSEG & VARPTR work in QB64!
If they aren't working for you, it's because of a glitch in V0.83 but I think that only related to VARPTR/VARSEG of user defined types. So just pass those values to a sub and use them using the standard DEF SEG, PEEK & POKE. What your program chooses to store at that location would depend on the level of compatibility you wish to provide. I'm unfamiliar what DQBPut expects to be there, but I'm guessing it's the standard [X*8],[Y],[pixeldata...] that QB uses to store its GET/PUT data.

For example:
Code: [Select]
screen 13

line(0,0)-(319,199),4,bf 'a big red screen!
dim b(10000) as integer
get (50,50)-(100,100),b(0) 'get the red stuff!
cls

line(0,0)-(319,199),1,bf 'a big blue screen!
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
I would think it is probably the same format too, however I am very bad at doing stuff like that, but I can learn from your example and we'll see where I land :)

I can also try to GET something then use DQBPut to put it and see if it is the same (which it should be if it is the same format), however, I don't think it matters if one uses exactly the same format that DirectQB does as long as it does the same thing. There seems to not be any difference between QBs GET/PUT and DirectQBs besides DirectQBs being faster.

My game that I work on in QB is getting out of memory soon so I'm really looking forward to see this working :)


EDIT: I've gotten this far:

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

width = px2-px
height = py2-py




off = off + 2

for dummyx = px to px2
for dummyy = py to py2
POKE off + dummyx + width * dummyy, c
next
next

END SUB

But I'm not that good at dealing with memory. I'll try my best though.
« Last Edit: June 02, 2009, 05:03:16 AM by Cyperium »
Venture - New Prototype, QB64 Editor v1.95b (linux compatible, if you compile the source).

  • Print