HANGMAN thread continues in GAMES.

[ahenry3068]

No code here yet. I got a copy of REMLINE.BAS from MSDOS 5.0. I Compiled it with the QB64 compiler after making one tiny change to the code. CONST Maxlines = 400. I changed to CONST Maxlines = 4000. QB64 while compatible doesn't have the memory constraints that QBasic used to have. I could have probably made it 40000 and the code would still run fine. But HANGMAN is about 1100 lines of code now and FRE(0) is < 14 kb already. 4000 is probably more than enough.

REMLINE Worked just fine on the CBM Basic source. . If a line is the target of GOTO, GOSUB, RESTORE or THEN the line number remains in the Output file. So I've got to go through and Search and Replace and come up with all labels. I started that process tonight but didn't finish yet. So I haven't been able to test HANGMAN under BASLOAD. Provided I get the conversion all done properly and BASLOAD can handle this size of BASIC Source I should be able proceed much more quickly to completion. I have the logic all mapped out in my head, but the program has just become pure LINE NUMBER HELL. I'm spending more time renumbering and moving stuff around the last few days rather than actually coding. So I'm taking the BASLOAD plunge.

REMLINE.BAS. Premodified for Maxlines = 4000. Just feed it to the QB64 compiler and Run it. Should compile under both Windows and Linux with no changes to the code.

REMLINE.BAS

(12.29 KiB) Downloaded 1096 times

[ahenry3068]

Ok I've got I would say 95 % success with BASLOAD. I'm happy because now I don't have to go write on offline source convertor . I was going to do that kind of an offline BASLOAD.. ADDLINES.BAS

I've got just a couple of glitches in the code output. Its really to late to look at those tonight. At the moment I do not think BASLOAD is at fault, Putting in Labels for all the line #'s was a pretty tedious task and I probably introduced the glitchs myself, I know I made 2 errors that BASLOAD flagged for me. 1 incorrect label name, and 1 duplicate label, I'm surprised that was all . I have to spend the next couple evenings fixing the glitchs, before I try to put any New code in. I'm off work Fri and Saturday and I expect those to be heavy coding days .

I feel kind of guilty not posting any update code, but I'm not doing that whiles its glitching.

[ahenry3068]

I am going have to write a REM stripping utility though. Just because my code is large enough that REM's are necessary for me to keep track of things but also take unnecessary RAM. A STRIPREM executable should actually be pretty easy to do. I'm probably going to make it an offline tool. Probably QB64.

[ahenry3068]

I had 4 visual glitches in the game on first successful conversion to BASLOAD format.

I've got 3 of them fixed. 2 of them were completely my fault, just relatively simple calling errors.

1 of them was kind of BASLOAD's fault, I wouldn't really call it a bug; BASLOAD handles lower case in quotes differently than CTRL/V to the emulator does. I was using the CTRL/V behavior when setting up my Intro Banner. I came up with a workaround using CHR$ so that's sorted.

I have 1 more glitch to solve then I'll be back where I started with the Line Numbered Code that I last posted, but in a much better position to proceed with new code.

[BruceRMcF]

I am going have to write a REM stripping utility though. Just because my code is large enough that REM's are necessary for me to keep track of things but also take unnecessary RAM. A STRIPREM executable should actually be pretty easy to do. I'm probably going to make it an offline tool. Probably QB64.

I wonder whether the system that lets you write in a more structured Basic which it transpiles into X16 ROM-Basic acts as a REM stripping tool as a free side-effect?

[ahenry3068]

I am going have to write a REM stripping utility though. Just because my code is large enough that REM's are necessary for me to keep track of things but also take unnecessary RAM. A STRIPREM executable should actually be pretty easy to do. I'm probably going to make it an offline tool. Probably QB64.

I wonder whether the system that lets you write in a more structured Basic which it transpiles into X16 ROM-Basic acts as a REM stripping tool as a free side-effect?

It does not. I did drop a suggestion to the developer though. I think it should drop REM's

[BruceRMcF]

I am going have to write a REM stripping utility though. Just because my code is large enough that REM's are necessary for me to keep track of things but also take unnecessary RAM. A STRIPREM executable should actually be pretty easy to do. I'm probably going to make it an offline tool. Probably QB64.

I wonder whether the system that lets you write in a more structured Basic which it transpiles into X16 ROM-Basic acts as a REM stripping tool as a free side-effect?

It does not. I did drop a suggestion to the developer though. I think it should drop REM's

It definitely should have that as an option. If I was using it, I would be treating the ROMBasic program similar to the binary assembled by my assembler. If I want to change anything, it will be in the original source, so the REM in the ROMBasic source would be pointless.

To be sure, some people who were more into CBM V2.0 would do tinkering in the ROMBasic program ... but for me, it would just be "the script for the ROMBasic interpreter".

[ahenry3068]

I wonder whether the system that lets you write in a more structured Basic which it transpiles into X16 ROM-Basic acts as a REM stripping tool as a free side-effect?

It does not. I did drop a suggestion to the developer though. I think it should drop REM's

It definitely should have that as an option. If I was using it, I would be treating the ROMBasic program similar to the binary assembled by my assembler. If I want to change anything, it will be in the original source, so the REM in the ROMBasic source would be pointless.

To be sure, some people who were more into CBM V2.0 would do tinkering in the ROMBasic program ... but for me, it would just be "the script for the ROMBasic interpreter".

I said much the same thing on the comment I left on the BASLOAD thread. I said I was treating it mostly as a Compiler and I didn't need REM's in my executables

BTW: In the past I have played with directly editing binary code on an X86 with a Disassembler/Hex Editor. Mostly for simple stuff, like maybe skipping over the entry of a software key . Not that I was ever a Pirate or anything .

[ahenry3068]

Source code now in BASLOAD format !!!!
Included Tokenized FILE to load.

As long as BASLOAD is taking up its own 8k of BASIC Ram it would be risky to run it under BASLOAD. BASLOAD is converting and loading it properly though. My current approach is to have two instances of the Emulator open. One has BASLOAD loaded to do the conversion. I then SAVE "@:HANGMAN.PRG" and then LOAD "HANGMAN.PRG" in the other instance of the Emulator to RUN it.

I'm exactly where I was now with the last line numbered Post, but the code is so much more readable. I did make 1 change because it was even simpler than I thought it was going to be. HANGMAN will use BVSAVE700.BIN if it is available, however if it isn't the functionality this Module provides is just disabled, if you don't already have a HANGBG.DAT the background Stage will just be redrawn every time. Previously if BVSAVE700.BIN was not present the program would stop with an error.


BASLOAD HANGMAN CODE, FIRST RUN

HANGMAN.zip

(30.07 KiB) Downloaded 1065 times

[ahenry3068]

I really shouldn't say this............ It might be bad luck.

I have such a complete picture in my Head of the rest of the Game Logic

As long as I'm keeping my Code just a little smaller than BASLOAD is able to handle. I might have a playable BETA release by Sunday.

I'm leaving ZSMKIT out of this until the Base Game Logic is done. I have plans for multiple Music files to be available. But doing GOSUBs for the whole ZSM Library is best left until the game is actually playable .

and just damn. I can do a GOSUB SET_ZSM_ISR. Rather then guessing what GOSUB 22350 actually means ....