XB Game Developers Package

[Opry99er]

Schweeeeeeet!!!! DLing tomorrow morning!!!

[LASooner]

Here is the XB Game Developers Package "Chardonnay" version. This fixes the IF/THEN/ELSE bug that was in "Bordeaux". As far as my testing shows, the only limitation is that you cannot have nested IF/THEN/ELSE statements.

Somehow an older version of COMPRESS found its way into the package; that has been replaced with the latest version.

Additions to XB256 and the compiler are CALL LINK("SYNC") which lets you tell a loop how long to take. I will post a video showing a digital clock that uses this

Another addition is CALL LINK("RUNL1") which lets you load and run an XB program from another, but without doing a prescan. This means that variables are carried through into the new program and you don't have to store them and then retrieve them.

I have removed the DV80 version that was compatible with a real TI. It is a lot of trouble to maintain two versions and I can't see any benefit in spending time on that. I'm getting 72 errors when compiling Aperture on a real TI - I think there is something wrong with the runtime routines but don't know what. The programs created with Classic99 are compatible with real iron and that's really all that matters. If people complain enough I could revisit this.

Already compiled my game with it, no issues so far

[Bones-69]

Same here. All good, no issues. :thumbsup

[senior_falcon]

This video shows the difference between RUN in XB and the new RUNL1 in XB256.

I have entered the two programs below, saved as DEMO1 and DEMO2. I then made a load program that loads XB256 and runs DEMO1 automatically when XB is selected.

DEMO1 creates a sprite, then pauses for a while to generate 100 square roots in the array SR( ). It then asks you to enter a string. When you press Enter line 170 loads and runs DEMO2 the normal XB way. When DEMO2 starts the sprite is still defined and on the screen which shows that character and sprite data is retained, but because of the prescan, A$ is a null string, all the square roots have been zeroed out, and the array size is the default DIM(10).

 

I then load DEMO1, turn line 170 into a comment so it will be bypassed and save it as DEMO1. Now line 180 will use RUNL1, a new subroutine in XB256, to load DEMO2. This loads an XB program that is in IV254 format, and goes to line 1, but without the prescan. You can see that, as before, the character definitions and sprite are retained, and A$ and all the square roots were passed instantly because there was no prescan. XB has no idea that it was duped and a new program was loaded, so it just keeps on running. Pretty cool, no?

 

Naturally, you wouldn't use this for programs of this size, but if you were writing very long programs that are chained together, this could be another useful tool to use.

100 ! 1st part of demo
110 DIM SR(100)
120 CALL CLEAR :: CALL SCREEN(4)
130 CALL CHAR(96,"0103070B0A1B2A2B2A2B4A4B4A7B0E0A0080C0A0A0B0A8A8A8A8A4A4A4BCE0A0")
140 CALL MAGNIFY(4):: CALL SPRITE(#1,96,5,100,120,-7,0)
150 FOR I=1 TO 100 :: SR(I)=SQR(I):: NEXT I
160 INPUT "ENTER A STRING: ":A$
170 RUN "DSK1.DEMO2"
180 CALL LINK("RUNL1","DSK1.DEMO2")

100 ! 2nd part of demo
110 CALL CLEAR :: CALL SCREEN(12)
120 PRINT A$
130 FOR I=1 TO 100 :: PRINT SR(I):: NEXT I
140 GOTO 140

Edited February 27, 2018 by senior_falcon

[senior_falcon]

Here is a demo of the new SYNC routine added to XBGDP "Chardonnay". SYNC is used to determine a precise amount of time a loop should take. In this case the program is meant to run in XB256 and simulates a digital clock. So you would want one second per loop or 60/60 seconds. The actual code takes about 1/2 second per loop in XB, but that doesn't matter. Whether it took 1/10 second or 3/4 second, SYNC would delay the loop just enough so it takes 1 second total. SYNCTEST-X is a compiled version of the program and you can see that it runs exactly the same. SYNC is not all that useful in XB, but it could be useful in smoothing out the action in a compiled game program. The delay might be 2/60 or 3/60 seconds in a compiled program. In testing, XB would take longer than the specified time, so it wouldn't delay any but would simply go on with the loop.

 

The compiled version was also a good test of the new IF/THEN/ELSE in the compiler. See line 160.

100 CALL LOAD(-1,60)
110 CALL CLEAR
120 INPUT "HOUR ":H
130 INPUT "MINUTE ":M
140 INPUT "SECOND ":S
150 DISPLAY AT(10,10):SEG$("0"&STR$(H),1-(H>9),2)&":"&SEG$("0"&STR$(M),1-(M>9),2)&":"&SEG$("0"&STR$(S),1-(S>9),2)
160 S=S+1 :: IF S=60 THEN S=0 :: M=M+1 :: IF M=60 THEN M=0 :: H=H+1 :: IF H=13 THEN H=1
190 CALL LINK("SYNC")
200 GOTO 150

[Opry99er]

Thats some super slick stuff there!!!

[Bones-69]

Possible bug in the new version??

 

Has happened to me a few times now. Nothing that "rebooting" (restarting Classic99), doesn't seem to fix. Thought it an odd one worth sharing....

 

[LASooner]

I'm not having this issue, have you tried it on http://js99er.net/?

[Bones-69]

I'm not having this issue, have you tried it on http://js99er.net/?

 

No - Haven't done much of anything other than report it. When it happens I close off Classic99, restart it and the problem goes away. Has spontaneously occurred a few times but I haven't noticed any pattern....

[Tursi]

Rather than closing Classic99, can you try using File->Cold Reset instead and let me know if that clears it? That will be help me understand if it's an emulation issue or a memory issue.

 

Also the debug log would be interesting to see. Your screens were flipping really fast... are you in Overdrive? (If so, also try again with Overdrive off. The faster CPU can interfere with some of the interrupt-based assumptions.)

[Bones-69]

Tursi,

 

- Tried cold reset using the File-> options but this did not correct. The few times I experienced the issue I could only resolve by restarting Classic99.

- I was in overdrive on all occasions (I think the only time I ever turn it off is when running a compiled program).

 

I was fooling around with Classic and the compiler all weekend without any repeated issues. If it happens again I will try and capture more useful information.

[+OLD CS1]

Apparently it is using New Math.

[Tursi]

Senior Falcon can correct me if this is mistaken, but a number of his XB tricks rely on the VDP interrupt happening before the GPL interpreter gets to a certain point. The faster CPU means that GPL is interpreting faster than normal compared to the VDP, so it's not impossible that is causing you issues.

 

You can test for that by trying System Maximum, instead, which maintains the system ratios (ie: the VDP speeds up too). I've traditionally discouraged it because it never worked quite as well and ate a lot of resources, but it's a little more stable these days. For what you're trying to do it may be better.

 

(I can't explain why the emulator would need to be restarted, but that points more to emulation issues than tool issues...)

Edited March 5, 2018 by Tursi

[unhuman]

I can't say how awesome and amazing the XB256 kit is... I had no idea that it'd be so easy to develop games with - the custom environment (gray screen) is amazing and makes integration so simple. Also, gray is better than cyan! If I knew this, I wouldn't've even starting coding in regular XB and been able to take advantage of more characters, etc. It just works.

[unhuman]

So, tonight I composed (well, converted) the music for my game. It's unfortunately way too large.... Are there any tricks to have longer sound lists? It'd be nice...

 

Edit: Nevermind. Just compiled it to data statements and it works just great. Documentation scared me.

 

BTW, sorry for all the spams. I'm pretty excited about what I'm doing and trying to keep moving. My code is pretty crazy. If I go away from it for too long, I probably won't be able to read it anymore.

Edited March 13, 2018 by unhuman

[Airshack]

Wonderful! Thank you Harry!

[Airshack]

 

 

 

I really dig what you've done so far, I was planning on writing up a tutorial on how I use the compressed data during development.

 

 

GREAT IDEA!

[unhuman]

FIX: I had a dyslexic number.

 

Having a problem with my Sound List. It works fine from the command line. Playing the music works and playing sound effects over it works fine too...

 

But, when I'm in my game, music works fine, but once the sound effect is played, the music stops and it plays just annoying tone indefinitely.

 

If I just take the merge file and only the merge file and do:
10 CALL LINK("PLAY",MUSIC)

20 CALL LINK("PLAY",SOUND)

it does the same thing (annoying indefinite)

 

Without revealing anything, here are the sound effect portions of my file:

2000 !SOUND
2010 !PLAYER2
2020 CALL SOUND(10, -5, 1)
2030 CALL SOUND(10, -5, 1)
2040 CALL SOUND(10, -5, 1)
2050 CALL SOUND(10, -5, 1)
2060 CALL SOUND(10, -5, 1)
2600 STOP

3000 !NOISE
3010 !PLAYER2
3020 CALL SOUND(33,110,0,-7,0)
3030 STOP

 

Any clues?

Edited March 17, 2018 by unhuman

[unhuman]

Attempting to Assemble... Get

 

UNDEFINED SYMBOL - 0005

[Opry99er]

Look at your /S file and see what the 5th line in the compiler assembly source file says.

[unhuman]

Not sure what this is, but...

 

TIFILES n€žPn ........................
ZERO DATA 0
ONE DATA 1
PI DATA 3
RND DATA 0ÿ NC1 DATA 1054NC2 DATA 6176NC3 DATA 7194NC4 DATA 7218
NC5 DATA 0
NC6 DATA 1NC7 DATA 50
NC8 DATA 2NC9 DATA 150
NC10 DATA 3NC11 DATA 350

 

 

Maybe because I'm using the old Random? Trying the new way.

Edited March 17, 2018 by unhuman

[LASooner]

FIX: I had a dyslexic number.

 

Having a problem with my Sound List. It works fine from the command line. Playing the music works and playing sound effects over it works fine too...

 

But, when I'm in my game, music works fine, but once the sound effect is played, the music stops and it plays just annoying tone indefinitely.

 

If I just take the merge file and only the merge file and do:

10 CALL LINK("PLAY",MUSIC)

20 CALL LINK("PLAY",SOUND)

it does the same thing (annoying indefinite)

 

Without revealing anything, here are the sound effect portions of my file:

2000 !SOUND

2010 !PLAYER2

2020 CALL SOUND(10, -5, 1)

2030 CALL SOUND(10, -5, 1)

2040 CALL SOUND(10, -5, 1)

2050 CALL SOUND(10, -5, 1)

2060 CALL SOUND(10, -5, 1)

2600 STOP

 

3000 !NOISE

3010 !PLAYER2

3020 CALL SOUND(33,110,0,-7,0)

3030 STOP

 

 

Any clues?

 

 

Your music is not using player 2 correct?

 

Because if it is that's what causing it. If it's not any standard CALL SOUND statement will also interrupt it

[unhuman]

The music is indeed *NOT* using player 2. I had it all working and sounding great - in XB. Then I went to compile and it won't and sounds bad back in XB. I am using > 640 bytes so I do CALL LINK("XB256", 1054) as directed as my first statement. Going to take a little break.

[LASooner]

You can't have the XB256 line in when you compile

[Retrospect]

You can't have the XB256 line in when you compile

Hi LaSooner

 

At which point do we have to use the line CALL LINK("XB256",xxx) to reserve memory? before the program is pasted in with the merged sound list?

 

I'm having the same trouble now, as I did a few years ago. My soundlists don't work when compiled. I've never been able to work it out even with the manual.