
Yep, it is completely impressively nuts. Already playable!
It will be interesting to see what kind of benefit you get out of managing spans or tile coverage with DSP but it's already looking close without that. If it gets faster still then *bonus*

Moderators: simonsunnyboy, Mug UK, Zorro 2, Moderator Team
calimero wrote:Is it wireframe version of game available for download? It runs in full speed on stock Falcon, right?
dml wrote:It will be interesting to see what kind of benefit you get out of managing spans or tile coverage with DSP but it's already looking close without that. If it gets faster still then *bonus*
Code: Select all
0000000000000000
0000011111100000
0001111111111000
0011111111111100
0011111111111100
0111111111111110
0111111111111110
0111111111111110
0111111111111110
0111111111111110
0111111111111110
0011111111111100
0011111111111100
0001111111111000
0000011111100000
0000000000000000
Anima wrote:Eero Tamminen wrote:It works otherwise fine also with EmuTOS (v0.9.4), except for joystick directions. Are you reading joystick data in some non-standard / TOS version specific way?
Ahhhh... thanks for your report! The joystick should work now. So when you want to play it please download the latest version again.![]()
Eero Tamminen wrote:Did you test the new version with EmuTOS [1] or did you just make the game more compatible with different TOS versions? Only joystick fire works still when using EmuTOS...
[1] Latest Falcon compatible version is the 512k one from here:
http://sourceforge.net/projects/emutos/ ... tos/0.9.4/
Strider wrote:Impressive! The game runs fast on 060. It is slower on 030 (although easier) but still playable.
Keep up the good work!
Eero Tamminen wrote:Only joystick fire works still when using EmuTOS...
Anima wrote:Strider wrote:Impressive! The game runs fast on 060. It is slower on 030 (although easier) but still playable.
Keep up the good work!
![]()
Did you notice frame drops on higher sprite count or is it stable? I would like to know if the sprite restoration code for faster CPUs needs an optimisation as well. Does the initial detection of the machine features work properly?
Anima wrote:Eero Tamminen wrote:Only joystick fire works still when using EmuTOS...
It seems that EmuTOS doesn't activate the IKBD joystick event reporting feature (IKBD $14)!? The fire button works because it is handled via the mouse button data packet.
anodyne wrote:Hi, thanks for your investigation! I'm an EmuTOS developer and I'd like to fix this. Which keyboard packets are you expecting that you don't get? And is this on Joystick 1 or Joystick 0?
Code: Select all
5.1 Joystick Event Reporting
In this mode, the ikbd generates a record whever the joystick position is
changed (i.e. for each opening or closing of a joystick switch or trigger).
The joystick event record is two bytes of the form:
%1111111x ; Joystick event marker
; where x is Joystick 0 or 1
%x000yyyy ; where yyyy is the stick position
; and x is the trigger
Code: Select all
9.15 SET JOYSTICK EVENT REPORTING
0x14
Enter JOYSTICK EVENT REPORTING mode (DEFAULT). Each opening or closure of a
joystick switch or trigger causes a joystick event record to be generated.
Anima wrote:anodyne wrote:Hi, thanks for your investigation! I'm an EmuTOS developer and I'd like to fix this. Which keyboard packets are you expecting that you don't get? And is this on Joystick 1 or Joystick 0?
Hi anodyne,
please have a look at this IKBD document: https://freeshell.de/~monokrom/monochro ... s/ikbd.txt
...
Hope this helps.
anodyne wrote:1. is the joystick connected to port 0 or port 1?
2. are you sending any commands to the IKBD during e.g. program startup?
Anima wrote:anodyne wrote:1. is the joystick connected to port 0 or port 1?
2. are you sending any commands to the IKBD during e.g. program startup?
I tested it so far only with joystick #1 but both are supported by the interrupt handler. I'm sending no command to the IKBD. So in fact I am assuming that the TOS "default" IKBD settings are active (I know: never assume anything).
Eero Tamminen wrote:Hm. So normal TOS enables joystick reporting at boot although there's nothing using joystick. Similarly to how it enables at boot the Falcon sound matrix sound output... (EmuTOS doesn't seem to by default enable things unused by its own desktop, like normal TOS does)
anodyne wrote:This looks OK, as far as I can see. Or am I missing something?
Anima wrote:I've made another test by setting a breakpoint on the IKBD interrupt routine and checking the incoming events after a clean boot. Actually there's no reaction while using the joystick. Tested on Ubuntu, Hatari 1.8.0 and EmuTOS 0.9.3.
Update: it works using EmuTOS 0.9.4! So I strongly recommend to use the latest version if you want to play it using Hatari.
Anima wrote:@Eero: I'll prepare a special Hatari version to remove the flicker.
Eero Tamminen wrote:Joystick (directions) didn't work originally with that EmuTOS version (0.9.4). As I've seen similar issue also in other games (mainly STOS ones), I'm very curious what you changed in Chorensa to get joystick working with EmuTOS?
Eero Tamminen wrote:Anima wrote:@Eero: I'll prepare a special Hatari version to remove the flicker.
How that version differs from the other version?
Eero Tamminen wrote:At least with latest Hatari (WinUAE CPU core) version from Mercurial, the "sz2_hatari.tos" flickers a lot more than "sz2.tos". Flickering happens only when there are more explosions, but then it's very visible, one can see it e.g. right at start by shooting at the depris (stuff that flies upwards in the beginning).
Eero Tamminen wrote:Also, would it be possible to get debug symbols included to the program:
shoggoth wrote:Works on the CT60+SuperVidel.
Socks flew off.
Anima wrote:Yes, Supervidel is supported. Can you please tell me if the initial text says that a Supervidel has been detected?
Users browsing this forum: No registered users and 2 guests