TI-REX - New running game for TI-99, Dinorunne Chrome clone.

[gekido_ken]

 

Try this:

Start the Classic99 emulator and run TREX-C in XB. It will run fine. Now break out of the game using FCTN-4 then type RUN again. You will see the behavior I described. Type NEW then RUN "DSKx.TREX-C" and the same issue is present. The only way to fix the game is to cold reset Classic99.

Now I don't know if the issue is with the emulator or your game or the compiler, but that was my observation...

 

In this case this problem is more than likely to happen.

The game is compiled, so if it is interrupted, it is allocated to the first available address.

For this reason that only with the reset everything works again.

I have to disable F4.

Edited April 2, 2018 by gekido_ken

[gekido_ken]

Speaking of latest versions, I see you are using an older version of the compiler. How do I know? The suffix for the EA5 version is -A and the XB version is -C. The newest version (Chardonnay) uses -E and -X for those versions. Download the newest version in the thread "XB Game Developer's Package". It is much easier to use - you will like it!

Dolcetto will be out soon. I am making a few more changes to it.

 

 

 

This is the version of compiler that I use.

 

If you release a new version, please link me, thanks.

Edited April 2, 2018 by gekido_ken

[senior_falcon]

Here you go:

 

http://atariage.com/forums/topic/224905-xb-game-developers-package/?view=findpost&p=3962153&hl=%2Bgame+%2Bdeveloper

[senior_falcon]

 

Try this:

Start the Classic99 emulator and run TREX-C in XB. It will run fine. Now break out of the game using FCTN-4 then type RUN again. You will see the behavior I described.

Try this: Break the game using Fctn-4. Then CALL LOAD(-31804,0,0). Then type RUN and see if that fixes it.

[+Vorticon]

Try this: Break the game using Fctn-4. Then CALL LOAD(-31804,0,0). Then type RUN and see if that fixes it.

 

Unfortunately it does not. It's not really a bug in the game itself and most people will not be breaking out of the game anyway, but I'm just curious as to why this happens. I'll have to test it out on real hardware and see if I can duplicate it there.

[senior_falcon]

 

I'm just curious as to why this happens.

Me too. RUN should reinitialize everything. See if it happens on real hardware and let me know.

[gekido_ken]

Me too. RUN should reinitialize everything. See if it happens on real hardware and let me know.

There is also on real machine.

[+mizapf]

Here is my try on MAME, first 60Hz, then 50Hz. The 50Hz looks a bit more choppy in the recording than it was during gameplay.

 

 

Also, here is the disk image for using in MAME.

tirex.dsk

[senior_falcon]

 

Unfortunately it does not. It's not really a bug in the game itself and most people will not be breaking out of the game anyway, but I'm just curious as to why this happens. I'll have to test it out on real hardware and see if I can duplicate it there.

I think this is a bug in the compiler. If you break the program before you die then you can RUN and the program behaves properly. If you die and then "press any TI key" you can break the program and RUN and the program behaves as expected. If you die and then break the program and RUN then the error happens. I will attempt to track down the cause of this.

 

<EDIT> Found it! Gekido-Ken is using CALL LINK("FREEZE") to kill the sprite motion. That plugs a value of >4000 into >83C2, stopping all sprite motion. When you break at this point the TI goes back to the XB interpreter command line. When you type RUN, the interpreter does not know that this has been changed, so it doesn't think to change it back to the default >0000. The fix will take one line, CLR @>83C2 and I just have to figure out where to put it. Looks like both XB256 and the compiler will need this fix.

Edited April 3, 2018 by senior_falcon

[gekido_ken]

Here is my try on MAME, first 60Hz, then 50Hz. The 50Hz looks a bit more choppy in the recording than it was during gameplay.

 

https://youtu.be/yDH8Czfsr44

 

Also, here is the disk image for using in MAME.

Mame use refresh of pc video driver and non real.

 

Classic99 is the emulator most near to real refresh.

 

This is recognize with cactus. In right refresh they follow speed scrolling of floor. If you use a wrong refresh version the cactus is not sinchronized on floor.

I've tested all version on real machine, and i can confirmed all things.

Even on real machine the 50hz version is more faster of emulator.

[+mizapf]

Actually, MAME does emulate the 50Hz and 60 Hz properly, it is not depending on the video driver. You can see that when you play games with the 50 and 60 Hz versions (which became pretty obvious in our game competition). If you see differences to the real machine we will have to fix that.

 

Edit: One thing comes to my mind... Maybe it is the fast RAM. I have to check this with the standard 32k expansion.

Edited April 3, 2018 by mizapf

[gekido_ken]

This video is recorded on classic99 set up on 60hz, running TI-REX version 60hz.

Look the cactus sinchronized with floor.

 

[+mizapf]

I suppose this is better:

 

 

The jerky movement is probably caused by simplescreenrecorder; it went much more smoothly when playing.

 

As I said, I changed the 32k memory expansion from the internal 16-bit 0 waitstate mod to the external 32k peripheral card for this video.

[LASooner]

Just an FYI, if you're running anything in windows 10 you can hit WIN+G and it will allow you to record a video of whatever window had focus when you hit it. It records audio and video in mp4 in your video directory, you can even record dialog over it if you have a microphone hooked up. I've found it results in better videos.

[+mizapf]

Using Linux.

[+Vorticon]

Just an FYI, if you're running anything in windows 10 you can hit WIN+G and it will allow you to record a video of whatever window had focus when you hit it. It records audio and video in mp4 in your video directory, you can even record dialog over it if you have a microphone hooked up. I've found it results in better videos.

 

Did not know that! Should come in real handy for quick videos.

[gekido_ken]

Hey guys!

I'm back on the topic to publish the first re-release of TI REX that works smoothly at both 50 and 60hz.

The main problem was the non-synchrony of the cacti with the floor, depending on whether you use the TI99 at 50 and 60hz. For this reason I had adapted two versions.

However, the obstacle sprites were moved with independent routines, so I had to calculate the movement speed to synchronize with the floor.

This version B1.2, on the other hand, chains the movement routine of the obstacles to the page update and therefore to the scrolling of the floor.

In this way the only difference that is noticed on machines at 50 and 60 Hz is the framerate.

The collisions and state "flags" that define whether the dinosaur is on the ground or jump, and those of activation and cancellation of sprite obstacles have been further improved.

Probably there will still be some updates, such as the use of the joystick in the next re-release.

In the meantime, download this version and ..... HAVE YOU FUN!

TIREX.zip

Edited April 4, 2018 by gekido_ken