Jump to content
Posted Mon Feb 26, 2018 12:23 AM
Posted Mon Feb 26, 2018 2:26 AM
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
Posted Mon Feb 26, 2018 4:32 AM
Same here. All good, no issues. :thumbsup
Posted Mon Feb 26, 2018 8:22 PM
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 by senior_falcon, Mon Feb 26, 2018 8:25 PM.
Posted Mon Feb 26, 2018 8:39 PM
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
Posted Mon Feb 26, 2018 9:46 PM
Posted Thu Mar 1, 2018 11:01 PM
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....
Posted Thu Mar 1, 2018 11:24 PM
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....
Posted Sun Mar 4, 2018 3:07 PM
Posted Sun Mar 4, 2018 8:16 PM
- 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.
Posted Sun Mar 4, 2018 8:21 PM
Apparently it is using New Math.
Posted Mon Mar 5, 2018 1:23 AM
Edited by Tursi, Mon Mar 5, 2018 1:24 AM.
Posted Sun Mar 11, 2018 8:58 PM
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.
Posted Mon Mar 12, 2018 8:29 PM
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 by unhuman, Tue Mar 13, 2018 6:50 AM.
Posted Tue Mar 13, 2018 11:36 PM
Wonderful! Thank you Harry!
0 members, 0 guests, 0 anonymous users