QBasic game programming • Hacker News Board

Re: QBasic game programming

#31

Post by jarcane » Mon, Jan 19, 2015, 7:16 PM UTC

DSMan195276 wrote: post #30

jarcane wrote: post #12

Earlier quoted context omitted.

There's also FreeBASIC, which is largely compatible but with some shiny new features on top (even macros and tail-call optimization O_O).

The QB64 community is aware of FreeBASIC, but a big feature of QB64 is that you can literally drop QBasic code into QB64 and it will work without any modifications. This won't work at all for FreeBASIC, it's much to far away from QBasic. FreeBASIC is still a nice language, but it does have different goals then QB64.

They've moved away then, since I last used it, earlier versions were pretty compatible. QB64's aims are good, but it's still incomplete itself, and I had stability issues with it (and to be honest, wasn't particularly keen on still using the old QB IDE anymore either).

Re: QBasic game programming

#32

Post by z3t4 » Mon, Jan 19, 2015, 7:27 PM UTC

QBasic was also how I started programming. When I found out you can edit the code ...

I printed programs on the school printer. Then typed it in when I got home, as we did not have any Internet. Sometimes I got banned for printing non-school-work.

I've heard similar stories from people printing machine code, so I guess it wasn't that bad writing QBasic.

Re: QBasic game programming

#33

Post by Narishma » Tue, Jan 20, 2015, 12:22 AM UTC

balau wrote: post #29

Narishma wrote: post #20

Is it me or is he doing the input and rendering in the wrong order?

Not necessarily wrong. Let's say it's inverted with respect to what you would normally expect. Since PUT writes pixels with XOR, it doesn't make a difference after the two PUT are executed. But since the graphic mode doesn't have double buffering, the screen could refresh while the PUT are executing. If the sprite is erased and then the next sprite is drawn, it might happen that you see no sprite or a partial sprite…

I was talking about input and rendering. If you do rendering before handling input, you add at least an extra frame of latency.

Re: QBasic game programming

#34

Post by balau » Tue, Jan 20, 2015, 7:55 PM UTC

Narishma wrote: post #33

balau wrote: post #29

Earlier quoted context omitted.

Not necessarily wrong. Let's say it's inverted with respect to what you would normally expect. Since PUT writes pixels with XOR, it doesn't make a difference after the two PUT are executed. But since the graphic mode doesn't have double buffering, the screen could refresh while the PUT are executing. If the sprite is erased and then the next sprite is drawn, it might happen that you see no sprite or a partial sprite…

I was talking about input and rendering. If you do rendering before handling input, you add at least an extra frame of latency.

I'm sorry I don't know why I understood the other thing. You are right, the input effect is delayed in this way.

Re: QBasic game programming

#35

Post by DSMan195276 » Tue, Jan 27, 2015, 7:24 AM UTC

jarcane wrote: post #31

DSMan195276 wrote: post #30

Earlier quoted context omitted.

The QB64 community is aware of FreeBASIC, but a big feature of QB64 is that you can literally drop QBasic code into QB64 and it will work without any modifications. This won't work at all for FreeBASIC, it's much to far away from QBasic. FreeBASIC is still a nice language, but it does have different goals then QB64.

They've moved away then, since I last used it, earlier versions were pretty compatible. QB64's aims are good, but it's still incomplete itself, and I had stability issues with it (and to be honest, wasn't particularly keen on still using the old QB IDE anymore either).

FreeBASIC definitely has moved away from QBasic compatibility, I don't think it's considered a focus at this point. The last SDL versions of QB64 are fairly impressively compatible IMO, a large chunk of QBasic programs work without too many modifications. You can also now use the compiler via the command-line if you're interested. Back when I was doing some more "serious" QB64 development, I use a regular IDE and shell'd out to QB64 to compile, rather then typing in the QB64 IDE itself. It has it's share of rough edges though, so it is what it is.