Asmusr

Deleted.

You have to move your data to VDP RAM before you can save it. And you can only load data from disk into VDP RAM.

Now with speech and a talking chest. 😃 raycaster.dsk raycaster.rpk raycaster8.bin The guards, being very polite, recognize that you're one handed.

Is that the Omega directive?

Thanks for the comments and suggestions. Just to explain, for a fast raycaster I think I'm well covered by the one I already made. If I decide to make another, texture mapped one, I'm well aware that it wouldn't run fast enough for an action game, but for a turn based RPG game it could be fine. See this video where I have set the speed to 2 FPS. It's moving 1 block at a time and turning 90 degress. I think that would be doable on the TI. I'm a big fan of RPGs like Might and Magic III. [video deleted by mistake]

That's for 60fps. But 2k is if almost all your instructions are movb to the vdp, which is difficult to achieve in practice.

This version has a superimposed 8x8 grid. Where do you see that slope?

That would be helpful since I have not programmed in Python before. My concern is that if it differs too much from the master branch it would no longer be emulating the TIPI. Doesn't the current programming model mean that the RPi is running with high CPU load 24/7? I wouldn't want my emulator to do that.

There is no issue on the TI/emulator side. The problem in on the python side where I need to use something like https://websockets.readthedocs.io, which is event driven/asynchronous. It's not possible to poll a websocket, so it doesn't plug into TipiMessage as it is.

Yesterday I looked into implementing TIPI support in JS99er. My idea was to use websockets as the interface between JS99er/TI and the python code, which would be slow, but I don't think that would matter for the emulation. I got stuck because the python code is implemented as a polling loop instead of being event driven. What would it take to reverse control so that TipiMessage is notified when a byte has been received instead of polling for it? For the normal code branch I guess it would mean moving the polling loop into libtipi.

This video is made on a PC, but it's showing graphics that the TI-99/4A would be capable of if it was fast enough. It's using the 4x1 fat pixel bitmap mode of the 9918A that you get by setting the pattern table to a fixed 11110000 pattern and only updating the color table. I'm pretty sure it wouldn't be fast enough on a TI for a first person shooter, but for a dungeon crawler game it might be fine.

If you want to speed things up you should look into how to avoid any VDP reads and how to avoid settings up the VDP write address more than once.

Just add a "breakpoint" like T(start-end), e.g. T(A000-A030) to count the cycles between >a000 and >a030.

I think sideways would be a lot easier.

No it doesn't. It even runs on MAME 🙂.

I agree that the floor color has to change, so I have used the yellows that I don't use anywhere else. And I have fixed the gun movement. raycaster.dsk raycaster.rpk raycaster8.bin

I'm experimenting with various things. One is the floor pattern, as you will see. You can also shoot the baddies now, but the baddies can't shoot you. raycaster.rpk raycaster8.bin raycaster.dsk

I have always been fascinated by Zaxxon, and it would be a nice challenge to make a port for the F18A. For the 9918A I think the MSX1 version is already as good as it gets.

There is a Zaxxons Trainer in the GameBase. It only has some sprites.

I never found out where the DSRLNK that BASIC uses is located, and why we don't use that from assembly. Is it because it's written in GPL?

The thing with GPL DSRs is that they only work from BASIC because assembly programs generally don't look for them.

It's not high on my to-do list because you can click manually through the sprites. Actually my to-do list is empty at the moment. 🙂

I thought so. I have uploaded the new beta version with more sprites and even more characters to https://magellan.js99er.net/ This version also includes an 'Open recent' feature.

If you're running Magellan in Windows 10 and it looks blurry, you can disable the scaling by opening the properties for the Magellan.exe file, click Compatibility, click Change high DPI settings, check Override high DPI scaling behavior, and choose Application from the list.

I have a question about how mag files should work with the super character set. Internally Magellan will always use the super character set, so you can change character set size freely without losing and data. But when a mag file is saved, should the number of characters be truncated to the current character set size? The former has the advantage that mag files are compatible with older versions of Magellan if you don't use the new feature. The latter has the advantage that you never lose data even if you changed to a smaller character set. The beta version is doing the former, but I'm leaning towards the latter. What do people think?