Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
old QB Defender game - anyone want to try to bring this up to speed?
#1
Here's an ancient QB version of Defender by Tim Truman from the 90s.

The original "QBDEFEND.BAS" failed because of deffn, so I turned that into a function.
It now runs but way too fast, so I added _Limit at line 248, which brought it back to normal speed.
That version is "QBDEFEND_v2.BAS". 

(I tried cleaning it up some more but "QBDEFEND_v8.BAS" fails with a subscript out of range error at line 2784.)

There are probably bigger problems with the program - ancient joystick, timer, adlib routines, writing to adlibs registers, a whole lot of stuff I don't understand.

If anyone wants to play with it, I am attaching the code!


Attached Files
.7z   qbdefend.7z (Size: 221.42 KB / Downloads: 70)
Reply
#2
It stopped being "QB-DEF-FN-DER".

What are arrays doing being REDIM'ed with -1? So the "v8" is worth more than the other source code? What is QBASIC.EXE doing packed with this 7Z file, is it allowed? LOL a good chance to run DOSBOX but no thank you, I have QB64(PE).
Reply
#3
(03-29-2023, 10:08 PM)mnrvovrfc Wrote: It stopped being "QB-DEF-FN-DER".

Ha ha ho ho and he he! 
?
Reply
#4
(03-29-2023, 10:08 PM)mnrvovrfc Wrote: What are arrays doing being REDIM'ed with -1? So the "v8" is worth more than the other source code? What is QBASIC.EXE doing packed with this 7Z file, is it allowed? LOL a good chance to run DOSBOX but no thank you, I have QB64(PE).

I realized I never replied to the rest of your message... 

v8 is just my last attempt at cleaning up the code, but I ended up breaking something. 

v2 is probably the one that people want to try playing with, because that's the one that runs.

I only included QBASIC.EXE because that was included with the game in the original download. Obviously you wouldn't need that unless you want to run the original program in DOSBox like you said. Otherwise it can be deleted!
Reply
#5
Hi 
Madscjr
running it in QB64pe after turnig  DEF FNRND into FUNCTION FNRND  I got a broken game that leaves so  many garbage on the screen.
Putting a _LIMIT 10 into main loop the result does not change.
Reply
#6
(03-31-2023, 05:34 PM)TempodiBasic Wrote: Hi 
Madscjr
running it in QB64pe after turnig  DEF FNRND into FUNCTION FNRND  I got a broken game that leaves so  many garbage on the screen.
Putting a _LIMIT 10 into main loop the result does not change.

I am seeing graphics but the player's ship doesn't get erased from the old position when you move (I had to hack on some new keyboard reading routines). Also it isn't drawing the mountains / terrain. 
The program is a mess, it could probably serve as a template or framework for someone who wouldn't mind rewriting the outdated QuickBasic 4.5 parts.
Reply
#7
Looking at the "QBDEFEND_v2.BAS":

"FNRND" function name (at very end) should be changed to "Random0" or something else througout the program. Maybe QB64 reserves "DEF FN" and anything that starts with "FN" and if not, it looks ugly calling anything starting with "FN".

One suggestion is to turn the string of "COMMON SHARED" to "DIM SHARED". "CHAIN" and "COMMON" are outdated. If this program uses another source code file it should be made part of one file, either physically or as '$INCLUDE. Using "COMMON SHARED" usually means more than one source code file with a group of the same variables to share information. But QB64(PE) requires us to bundle up those small parts into one file if at all possible, it's an inherent limitation it's had since the beginning.
Reply
#8
(03-31-2023, 09:48 PM)mnrvovrfc Wrote: Looking at the "QBDEFEND_v2.BAS":

"FNRND" function name (at very end) should be changed to "Random0" or something else througout the program. Maybe QB64 reserves "DEF FN" and anything that starts with "FN" and if not, it looks ugly calling anything starting with "FN".

One suggestion is to turn the string of "COMMON SHARED" to "DIM SHARED". "CHAIN" and "COMMON" are outdated. If this program uses another source code file it should be made part of one file, either physically or as '$INCLUDE. Using "COMMON SHARED" usually means more than one source code file with a group of the same variables to share information. But QB64(PE) requires us to bundle up those small parts into one file if at all possible, it's an inherent limitation it's had since the beginning.

I agree with all you said. I'm pretty sure it's just the one file.

From what I saw in the code so far, it isn't a 100% exact copy of Williams' arcade game, like the pixel-perfect recreations that TerryRitchie and RokCoder have spoiled us with! (Not to mention, MAME!)

Maybe it was just never finished but I noticed there is no hyperspace function, what graphics still work in QB64PE don't look exactly like the original (more like the 8-bit home versions from back in the day), and in the code the different aliens aren't named what us old time Defender/Stargate fans know by heart - Baiters, Pods & Swarmers are called by different names for example.

But the game rules are close enough, the radar screen displays correctly, and the general game logic seems mostly decent, which is why I don't think it's a lost cause. Of course, any one of our star QB64/PE programmers (and there are a few - you know who you are!) would do a much better job than someone like me hacking around, but I think it would be fun for any fan of the original game to tinker with.

I'll post the code I got semi-working later when back at the PC.
Reply
#9
(03-29-2023, 09:26 PM)madscijr Wrote: Here's an ancient QB version of Defender by Tim Truman from the 90s.

The original "QBDEFEND.BAS" failed because of deffn, so I turned that into a function.
It now runs but way too fast, so I added _Limit at line 248, which brought it back to normal speed.
That version is "QBDEFEND_v2.BAS". 

(I tried cleaning it up some more but "QBDEFEND_v8.BAS" fails with a subscript out of range error at line 2784.)

There are probably bigger problems with the program - ancient joystick, timer, adlib routines, writing to adlibs registers, a whole lot of stuff I don't understand.

If anyone wants to play with it, I am attaching the code!

I'll take a look at it. Thanks for posting.
New to QB64pe? Visit the QB64 tutorial to get started.
QB64 Tutorial
Reply
#10
(03-31-2023, 07:16 PM)madscijr Wrote:
(03-31-2023, 05:34 PM)TempodiBasic Wrote: Hi 
Madscjr
running it in QB64pe after turnig  DEF FNRND into FUNCTION FNRND  I got a broken game that leaves so  many garbage on the screen.
Putting a _LIMIT 10 into main loop the result does not change.

I am seeing graphics but the player's ship doesn't get erased from the old position when you move (I had to hack on some new keyboard reading routines). Also it isn't drawing the mountains / terrain. 
The program is a mess, it could probably serve as a template or framework for someone who wouldn't mind rewriting the outdated QuickBasic 4.5 parts.

The same is my experience after changing DEF FNRND to FUNCTION FNRND  (there is no global variable changed here, so localization does not break anything)  and after adding _LIMIT 10 to get a more slowed output.
Moreover the ship moves alone without my input and fires by itsself.
I hear no sound in the game also if there are 2 functions to manage the soundblaster.


However I think that the main issue is the massive direct access to the registry of graphic card and of soundblaster card...
why? Because if you kook into functions Adlib and AdlibFx (num)  you see a massive calling of SUBroutine WirteReg(reg,value) that in its turn uses massively  OUT and INP ...
well, this QBasic keywords are emulated and there is no real direct access to a specific port of Motherboard (direct hardware access)
see QB64 Wiki for detailed informations: OUT wiki page  INP wiki page.[/url]

Joystick function also uses INP and OUT
Keyboard function uses PEEK to get status of keys Ctrl and Alt, and Peek/Poke are emulated into QB64 read here [url=https://qb64phoenix.com/qb64wiki/index.php/PEEK]Peek wiki page
.

In colllision the laser are not checked against colonists.


I agree with mnrvovrfc  that the global variables are declared in wrong way using COMMON, because COMMON has its goal into declaring global variables  shared among two or more programs linked with CHAIN keywords  COMMON wiki page
this is a CHAIN/ COMMON SHARED related thread CHAIN thread
Reply




Users browsing this thread: 2 Guest(s)