Jump to content
IGNORED

XB Game Developers Package


senior_falcon

Recommended Posts

Thank you for providing the new version.

 

I will test it tomorrow.

 

The response times are much better than in the basic version, time for a few more Stratego games.

 

Thank you! It's hard for me to be objective because I am obviously intimately familiar with the AI's workings.

Barring any compiler-related issues, I'm going to move that discussion to the dedicated Stratego thread and will be updating the files and manual there after I hear back from you.

 

I have to say that this project has eminently demonstrated the power of the XB compiler even with very complex programs, allowing the programmer to freely use XB for its ease of programming, especially when coupled with Matthew180's TIdBiT, then end up with an assembly-speed final product.

  • Like 2
Link to comment
Share on other sites

 

Thank you! It's hard for me to be objective because I am obviously intimately familiar with the AI's workings.

Barring any compiler-related issues, I'm going to move that discussion to the dedicated Stratego thread and will be updating the files and manual there after I hear back from you.

 

I have to say that this project has eminently demonstrated the power of the XB compiler even with very complex programs, allowing the programmer to freely use XB for its ease of programming, especially when coupled with Matthew180's TIdBiT, then end up with an assembly-speed final product.

 

Some credit has to go to you for pushing the envelope as well.

 

This caused a "rise to the occasion" response so the combination has been wonderful to observe. Truly outstanding IMHO.

 

Congratulations to all involved.

 

Now about creating "an Assembly-speed final product" … I suspect some Assembly language coders would beg to differ. ;)

  • Like 1
Link to comment
Share on other sites

OK so maybe near-assembly speed :) There is no question that nothing can match the power and flexibility of pure assembly language, but for complex projects, it can be extremely time-consuming. I have a half-finished science fiction wargame programmed entirely in assembly that's been sitting idle for years now because I can't bring myself to re-familiarize myself with the massive code (Ultimate Planet - http://atariage.com/forums/topic/162102-ultimate-planet/page-1?hl=+ultimate%20+planet ). I am still committed to finishing it, something I tell myself every year!

 

So to be honest, at least for projects not requiring complex floating point calculations or high res graphics needs, there is very little reason not to just use XB and then compile. Forth, of course, is also a contender, but there is a learning curve there.

 

There might be some chest thumping going on when one produces something in assembly, but really all that matters is the end-result and one is no less a programmer by sticking to XB alone.

  • Like 2
Link to comment
Share on other sites

I have a half-finished science fiction wargame programmed entirely in assembly that's been sitting idle for years now because I can't bring myself to re-familiarize myself with the massive code (Ultimate Planet - http://atariage.com/forums/topic/162102-ultimate-planet/page-1?hl=+ultimate%20+planet ). I am still committed to finishing it, something I tell myself every year!

 

 

 

At the risk of sounding like a broken record, a large assembly project might benefit from using a Forth Assembler.

You get the speed of Assembler, but you can write it in bite-sized chunks and test interactively, which can lead to improved productivity.

  • Like 1
Link to comment
Share on other sites

Here is "ISABELLA2". This has all the bug fixes developed in the course of the past few weeks getting Stratego to work and as far as I know it is complete. There was one quirk that I left in. That was found by Vorticon when he tried to display a print list using SIZE and found that the line was cleared all the way to the right side of the screen. I tried to fix this but found that the fix changed the display/print behavior elsewhere. It would take weeks of testing to get this all exactly the same as XB, so I decided to change the docs to describe the limitation.

 

I made a minor addition to the utility XB32K that allows the programmer to use all 32K of expansion memory for an XB program. It is more thoroughly tested and the docs go into much more detail. This is now part of XBGDP.

 

(edit) A bit of a snag. 256DEMO always compiled fine. Now it doesn't, so I am trying to work out what is going on.

Edited by senior_falcon
  • Like 7
Link to comment
Share on other sites

Wonderful! One question: can you confirm that the structure below now works with Isabella 2.0? It would not have worked with 1.0, but I recall you fixed that. I'm experiencing some odd behavior which could potentially be related to that piece of code (maybe...).

 

EDIT: No that was not it after all... Never mind me.

IF EMOVED(I)=1 THEN
	IF HFLAG=0 THEN
		HFLAG=1::
		GOTO search_loop ..
	ELSE
		SCORE=-1::
		TFLAG=0::
		GOTO next_square
Link to comment
Share on other sites

Here is ISABELLA2. (again)

As often happens, I added a couple of lines for one tiny feature, and surely that could not mess anything up. Famous last words...

Anyway, that's fixed and as far as I know all works as it should.

Anyone who downloaded the first version I posted should junk that and get this one.

ISABELLA2.zip

Edited by senior_falcon
  • Like 6
Link to comment
Share on other sites

So Harry, I was experimenting with the possibility of combining the Stratego initialization and main programs into a single program and then using the full 32K to run it. It compiles fine, but when the assembler runs the symbol table overflows. Is there a way to mitigate that issue at all?

Link to comment
Share on other sites

Check that your disk is set up properly. What you sent is not a proper text file. What is at the top is the beginning of the file you sent. What is below that is how it should look

 

TIFILES†€ÀP† DEF RUNEA,RUN,RUNV,CONRUNEA DATA ENDCC-RUNEA DATA RUNEA5FRSTLNL100 DATA CHAR,NC1,SC1L110 DATA CLEARL120L130L140L150FOR1# DATA FOR,NV1,NC2,NC3,ONE,0,0" DATA INPUTN,NC2,NV2,NV3,NV4ÿ DATA COLOR,NV2,NV3,NV4 DATA NEXT,FOR1+2L160 DATA SCREEN,NC4L170FOR2# DATA FOR,NV1,NC2,NC5,ONE,0,0 DATA INPUTN,NC2,NV5,SV1 DATA CHAR,NV5,SV1 DATA NEXT,FOR2+2L180FOR3# DATA FOR,NV6,NC2,NC6,ONE,0,0ÿ ! DATA HCHAR,NV6,NC7,NC8,NC9 DATA NEXT,FOR3+2L190FOR4$ DATA FOR,NV1,NC2,NC10,ONE,0,0L200 DATA MLTPLY,RND,NC9,NT1 DATA INT,NT1,NT2 DATA ADD,NT2,NC7,NT3 DATA LET,NV7,NT3L210 DATA MLTPLY,RND,NC6,NT1ÿ DATA INT,NT1,NT2 DATA ADD,NT2,NC2,NT3 DATA LET,NV6,NT3L220 DATA MLTPLY,RND,NC11,NT1 DATA INT,NT1,NT2 DATA ADD,NT2,NC2,NT3 DATA LET,NV8,NT3L230 DATA CLE,NV8,NC7,NT1 DATA IF,NT1ÿ

       DEF RUNEA,RUN,RUNV,CON
RUNEA  DATA ENDCC-RUNEA
       DATA RUNEA5
FRSTLN
L8
       DATA PRINT,SC1
       DATA GOSUB,L10000
L9
L10
       DATA LET,NV1,NC1
       DATA LET,NV2,NC2
L11
       DATA PRINT,SC2
       DATA GOSUB,L10000
L15
       DATA SCRN2
       DATA PRINT,SC3
       DATA GOSUB,L10000         
Link to comment
Share on other sites

So it looks like the compiler outputs the text file in TIFILES format. I went ahead and listed it in TIDir then copied the text into a text editor then saved it back. Also the runtime routines needed to be loaded in low memory during compilation.

In any case, it worked! Now there in no further need to save and re-load the game data when transitioning from the initialization to the main program as it is all a single program taking most of the 32K available. Unfortunately, disk access is still needed to load the character definitions and to go from the splash screen to the main game. Also I had to trim the battle sounds to make everything fit into XB before compilation.

Nonetheless, this opens up quite a bit of options for the XB programmer with all of the 32K available. Really outstanding capability!

  • Like 3
Link to comment
Share on other sites

So it looks like the compiler outputs the text file in TIFILES format. I went ahead and listed it in TIDir then copied the text into a text editor then saved it back. Also the runtime routines needed to be loaded in low memory during compilation.

 

This should not be necessary. You have to check "Write DV80 as windows text." Refer to the manual (there is a screen shot) and be sure the disk is set up properly. If it is then Classic99 it will directly output a standard text file.

(edit) It isn't the .TXT that makes it a text file, it is checking "write DV80 as windows text".

Edited by senior_falcon
Link to comment
Share on other sites

I thought I had done that. Must have forgotten this time around...

Question: I still have memory left after the compilation process, but it is not usable because adding any more lines to the XB program will lead to a memory full error when trying to load it. I really would like to move the character data off disk and into DATA statements using that extra memory. Is there a way to do this at all?

Link to comment
Share on other sites

Question: I still have memory left after the compilation process, but it is not usable because adding any more lines to the XB program will lead to a memory full error when trying to load it. I really would like to move the character data off disk and into DATA statements using that extra memory. Is there a way to do this at all?

Another way that should work would be to separate the program in two parts, PART1 and PART2. Save these in Merge format. Write a short XB program to OPEN "DSK1,PART1", input and OPEN "DSK1.PARTS12",OUTPUT. Read part1 and write each line to PARTS12. When at the end of PART1 then OPEN "DSK!.PART2",input. Then read each line of PART2 and write them to PARTS12.

 

There would be no way to test the program with this technique, but it should work.

Link to comment
Share on other sites

I tried this program to combine the 2 parts of Stratego as you detailed above, each saved in Merge format, but I got gibberish in the target file STRATEGO-M. Is my process correct here?

10 CALL CLEAR
20 OPEN #1:"DSK2.STRATEGO-M",OUTPUT
30 OPEN #2:"DSK2.STRATUP",INPUT
40 LINPUT #2:L$
50 PRINT #1:L$
60 IF EOF(2)THEN 80
70 GOTO 40
80 CLOSE #2
90 OPEN #2:"DSK2.STRATLO",INPUT
100 LINPUT #2:L$
110 PRINT #1:L$
120 IF EOF(2)THEN 140
130 GOTO 100
140 CLOSE #2
150 CLOSE #1
160 END

Link to comment
Share on other sites

You have to match the file characteristics. Default is Display, Variable 80. I can't remember what they are for Merge format. (It might be IV 163) If you can't find it easily you should be able to look the COMPILER program and find out..

Edited by senior_falcon
Link to comment
Share on other sites

I think it's going to be a moot point...

I used XB32K to create a single large program including the character definitions data, but unfortunately the loader reported -1302 bytes of memory left and hung. I guess I'm short about 1.3K of RAM beyond the 32K...

It was a valiant effort :)

By the way, even with the option to write DV80 files as Windows text turned on in Classic 99, I'm still getting a TIFILES output.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...