so i think i know my plan of attack.
-
@eniko Ooooh though could you have the first page be 100 displayed, but the offset to the second page start at line 104 instead of line 100? It might just fit, 320x204 = 65280 < 65536...
@tonyg hmm yeah that's a possibility. but none of the qbasic drawing functions would work on that last 4 lines, so that's kind of a problem
i suppose i could cut those lines and go with 160x96 instead of 160x100?
-
@eniko Wow, this sure brings back memories. QBasic...
@Craigp its a lot of fun working around the limitations
especially since i'm not using the faster compiled one and i refuse to use assembly tricks -
im filling the screen with tiles using PUT and then page flipping as fast as i can. i know dosbox isn't that accurate, but i set the cpu type to 386 and set cycles to 6000 which the conf file suggests is 386-ish (i found somewhere else that said 7800 is better so if anything its running slow)
and it's running at 52 fps
@eniko It's very approximate, but 6000 would be apx a 386 at almost 33MHz. So yeah, it's a 386, but a pretty fast one.
Well, most basic was originally meant to run on crazy low stuff like an 8088, so if you're emulating a decent system it's going to go pretty well I guess.
-
im filling the screen with tiles using PUT and then page flipping as fast as i can. i know dosbox isn't that accurate, but i set the cpu type to 386 and set cycles to 6000 which the conf file suggests is 386-ish (i found somewhere else that said 7800 is better so if anything its running slow)
and it's running at 52 fps
notched it up to 486 33mhz and added a vblank wait and now its rocking a steady 70fps
-
@tonyg hmm yeah that's a possibility. but none of the qbasic drawing functions would work on that last 4 lines, so that's kind of a problem
i suppose i could cut those lines and go with 160x96 instead of 160x100?
@eniko Oh, I see. Yeah, on the second page. That's a shame!
-
@eniko Oh, I see. Yeah, on the second page. That's a shame!
@tonyg its fine to be honest. making my own variable width font means i'll be able to cram way more text onto the screen anyway, even if its a bit of a pain
-
@Craigp its a lot of fun working around the limitations
especially since i'm not using the faster compiled one and i refuse to use assembly tricks@eniko When I was using it, I didn't even know what a compiler was. And if I left the machine on for more than an hour, it would overheat and begin randomly flipping bits.
Enforced breaks, probably should be part of modern machines too.
-
@eniko When I was using it, I didn't even know what a compiler was. And if I left the machine on for more than an hour, it would overheat and begin randomly flipping bits.
Enforced breaks, probably should be part of modern machines too.
@Craigp i tried to make games that ran well but i never got anywhere with it. coming back to it now is like sweet revenge :'D
-
notched it up to 486 33mhz and added a vblank wait and now its rocking a steady 70fps
@eniko For a bit of scale, 6000 cycles may be potentially achievable on a 3DS (albeit with shortcuts and less than stellar accuracy in emulation.) I think a Raspberry Pi 3 can possibly handle the 12000ish you're talking about there. Maybe a RPi 2, not sure. (But probably not a 1 or a zero.)
-
notched it up to 486 33mhz and added a vblank wait and now its rocking a steady 70fps
since the pixels are double wide, i wonder if i can do "alpha blending" between colors in the palette by just having one on the left half and another on the right half and alternating every frame
-
now i gotta decide if i wanna do this inside the qbasic IDE for retro charm or if im just gonna use notepad++ on my workstation with a dosbox launcher
@eniko nostalgia aside, one of the great things about qbasic is that it has an actually-working debugger and interpreter, and you can stop your program anywhere, make edits, evaluate immediate code to adjust state, and resume on the fly. doing all the coding offline would lose all that
-
since the pixels are double wide, i wonder if i can do "alpha blending" between colors in the palette by just having one on the left half and another on the right half and alternating every frame
i'm gonna do so many cool tricks with this it's gonna be great
like if a demoscener made a jrpg on dos
-
i'm gonna do so many cool tricks with this it's gonna be great
like if a demoscener made a jrpg on dos
like imma be real with you im not that interested in making a whole ass game but i am interested in making juuuuust enough of a game that i can show off the cool stuff i wanna do >_>
-
like imma be real with you im not that interested in making a whole ass game but i am interested in making juuuuust enough of a game that i can show off the cool stuff i wanna do >_>
@eniko so not porting block game to qbasic?
-
@eniko so not porting block game to qbasic?
@minirop i'm not *that* masochistic
-
like imma be real with you im not that interested in making a whole ass game but i am interested in making juuuuust enough of a game that i can show off the cool stuff i wanna do >_>
hmmm. realized that horizontal scrolling is tricksier than i initially thought. there may be some 8 pixel smear on the left and right sides of the screen while scrolling
to be fair it's not like anyone ever seems to mind the scrolling artifacts of other old systems so eh, i'll live
-
hmmm. realized that horizontal scrolling is tricksier than i initially thought. there may be some 8 pixel smear on the left and right sides of the screen while scrolling
to be fair it's not like anyone ever seems to mind the scrolling artifacts of other old systems so eh, i'll live
@eniko On the C64 you can make the borders wider for exactly that reason.
-
hmmm. realized that horizontal scrolling is tricksier than i initially thought. there may be some 8 pixel smear on the left and right sides of the screen while scrolling
to be fair it's not like anyone ever seems to mind the scrolling artifacts of other old systems so eh, i'll live
oh wait actually. i can build the scrolling columns using PUT, then GET 1 pixel wide slices. that way it's still perfect smooth scrolling with 16 PUTs for the sides
and if building the slices all at once is too much overhead for a single frame i can do it over multiples
edit: in fact not even that, the slices could be N pixels wide, so its literally just 1 put per column while scrolling horizontally
-
oh wait actually. i can build the scrolling columns using PUT, then GET 1 pixel wide slices. that way it's still perfect smooth scrolling with 16 PUTs for the sides
and if building the slices all at once is too much overhead for a single frame i can do it over multiples
edit: in fact not even that, the slices could be N pixels wide, so its literally just 1 put per column while scrolling horizontally
@eniko I'm jealous of you programming on a system that lets you do multiple gets and puts per frame and not slow everything to a crawl.
-
J jwcph@helvede.net shared this topic
