Asmusr

I'm thinking about doubling the height of the bottom panel from 32 to 64 pixels. Not only would it improve performance a bit, it would also allow me to store the screen buffer in one SAMS bank, which would free up 5KB address space, and it would allow the compass to be moved out of the screen and make room for other controls. The downside, of course, is that the 3D area is reduced, but in fat pixels it would still have twice as high resolution vertically than horizontally (64x128). I don't want to change the aspect ratio further, which would make the doors wider than they are tall, so I would just cut off 16 pixels at the top and bottom. Here is a mockup:

Thank you for the suggestion, but I prefer to keep it as it is. 🙂

Yes. Everything is experimental right now.

Magellan is great for making 8x8 characters for a tile map, but it falls short when you want to create bigger graphics. For my raycaster project I also needed an editor that could work with rectangular pixels, e.g. 4x1, and could shift an image left/right/up/down to check that textures were wrapping seamlessly. I couldn't find an existing bitmap editor that fulfilled these criteria, so I decided to create my own, browser based editor Raphael: https://raphael.js99er.net/ (named after the artist contemporary with Magellan). The colors palette is limited to that of the 9918A. It supports the color restrictions of bitmap mode and graphics mode but can also be set to work without restrictions. It's really slick and easy to use, but is subject to the usual limitations of a browser (no save - only save as, for instance). The import/export options are, at the moment, limited to assembly and my own needs, but if anyone would like to use the application and has suggestions for import/export formats please let me know.

Did anyone but me complete the game? Did anyone have issues loading saved games? Is there a problem with the disk images (as mentioned earlier) that should be resolved?

Thanks, but I think I will keep the arrows where they are. 🙂

How would you move with the mouse then?

Latest video: texcaster.rpk texcaster8.bin

Well done. With all those games you're able to compile, I wonder how you get around the limitations of the compiler, especially the lack of floating point?

Yes, I have been working on several new features including an inventory, keys and other items to pick up, a bigger on-screen map, a score/gold panel, and 'mouse pointer' interactions like pressing secret buttons and unlocking doors with keys. I have also worked on being able to place monsters and items on the map in Magellan and auto-generating the level data from the Magellan file. It's still in the stage of creating a framework for a game rather than creating an actual game.

Maybe this helps: The SAMS card doesn't have 32K in addition to 1M. The 32K you see with a SAMS card consists of some banks of the 1M mapped into the 32K memory space.

The frames are all there in the cartridge bin. The first frame starts at offset 300 hex. It consists of: Color table: 32 bytes Total number of patterns in frame: 1 byte Number of patterns for run 1: 1 byte Start pattern index for run 1: 1 byte Patterns for run 1: number of patterns * 8 bytes ... Number of patterns for run n: 1 byte Start pattern index for run n: 1 byte Patterns for run n: number of patterns * 8 bytes Name table: 768 bytes End marker: 1 byte. 255 if last frame in ROM bank, 0 if next frame is in the same ROM bank. The next ROM banks starts at address 2000 hex, 4000 hex, and so on and the first frame in a bank is always at offset 300 hex.

We know that we need at least two adjacent pixels of the same color to ensure that the color is recognizable on NTSC screens, so there is a chance that the resolution is high enough for artifact colors. We only have two patterns that could be useful for generating solid artifact colors: 10101010 and 01010101. Combined with the 16 base colors (maybe that's only 14 or 15 because of black and transparent) that could give up to 32 artifact colors with a resolution of (maybe?) 64x192. My hardware is packed away at the moment so I don't have any way to test it.

It means you have two screen buffers: one that's displayed and another where the next frame is being drawn. When the frame is ready you show that buffer instead and start drawing the next frame in the buffer that was displayed before, and so on. If you sync the buffer flipping with the VPD's vertical refresh you can get flicker free animations. The 9918A is good at double buffering because you can choose where in VRAM the different tables are stored. Double buffering is most important at high speed and when you change multiple tables at the same time, e.g. patterns and name table.

There is about 15 mins playtime in this version corresponding to the ARCADA part of the solution.

It's described here I think I added some special code to Magellan to import the frames. I don't have the file, but you can try to make a screendump from an emulator and import it into Magellan, just to get an idea.

It's very impressive how you can move behind the furniture. It's implemented by dynamically changing the sprite patterns.

I managed to solve the game by some accidental cheating. I reached one of the final rooms on disk 3, where I saved and died. When I loaded I was suddenly inside the escape pod, and could perform the final steps to complete the game.

Aargh, there is a time limit too.

The reason I'm asking is that the only difference between NTSC and PAL with respect to speed should be when something is interrupt driven, which for XB means sprite movement or sound. And I would assume the difference is the same compiled or not.

Does compiling make the difference between NTSC and PAL bigger?

Yes if is was to be assembled as an E/A#5 file it would usually contain the graphics. Yes it should work, because I have been assembling it. But without the cartridge with the graphics the screen will be filled with garbage when you run it. The source code is already commented. The code is not responsible for generating the graphics. There is no code to rotate on zoom in there. It's just sending graphics from the cartridge to the VDP as fast as possible. If you know how the VDP functions it should be pretty simple. It's nothing like the smooth scrolling where there is an algorithm to describe.

It should be assembled using xas99. The graphics are not in the source code. If you place a breakpoint at >6020 in rotozoom8.bin you will should the code there.

No, if you branch to >1FFF it will branch to >1FFE, which is where the 'e' is.

So even if the instruction LI R0,1 starts at >2000 the LABEL still has the value >1FFF. That's exactly why you need to use EVEN after the text and before the label. Otherwise if you branch to LABEL you will execute the last 'e' of 'Example', whatever instruction that might correspond to.