Asmusr

I think the majority of rpk files that people want to create today would have the type set to paged378. There seems to be little need to create an inverted cartridge or a specific 2 bank cartridge.

Yes, exactly like my wife.

As mentioned before, I have been considering changing the texture resolution from 16x64 to 32x64. I tried with the eye, and a new 32x64 texture looks like this: Whereas the old 16x64 texture looks like this:

I don't know, most people look kind of magenta to me 🙂

I like Wad's Palette, but also this: You would have many more options for blending colors into each other than for the 9918A palette.

I agree. But a dedicated stack pointer with push and pop, like the F18A GPU has, would have been very useful.

How about the transparent color 0, is the value it provides worth spending a palette index on?

Like this: https://codebase64.org/doku.php?id=base:fast_sqrt

I think we all agree that the colors of the TI-99/4A (9918A) palette are not optimal. What do you think the ultimate 16 color palette would look like? Please post your suggestions, and remember that a picture is worth a thousand words. Bonus for considering some degree of backwards compatibility with the old palette.

Zip your bin together with a layout file like the attached (edit name of romimage) and call it rpk. layout.xml

I fixed an error in the texture drawing code, so instead of this: We now get this: @artrag Thank you for the suggestions regarding sprite drawing optimizations. I haven't decided how to proceed with that yet.

VSPEEK should not restore R1 because that's where the return value is stored.

It depends on what you mean by animated, of course.

Yes.

It only works to use a fixed image for floor/ceiling when you move one square at a time.

One of the things I learned from watching "HIGH SCORE" on Netflix was that some of the games for the SNES (Star Fox) had a co-processor on the cart. I have several ideas where something like that could be useful. The thing I don't understand if how a co-processor on a cart would interact with the normal CPU.

Now the eye is there, so I just need to add the beholder. 🙂 From now on SAMS is required to see all the textures. If you only have 32K you better like treasure chests, because there will be a lot of them.🙂 The main new thing is of course the objects (eyes, chests), and most of the features are now working as in the non-textured version. The object drawing is slow because no cheating is involved. It's scaling and drawing the textures in real time. And it also has to support transparency, which makes it difficult to optimize in the same way as the walls, because the unrolled code would have to depend on the textures. Maybe if the textures were not allowed to have interior transparent sections, like the weird 'grating boss' I'm shooting at the end of the video, it would be possible to optimize? @artrag will probably know what to do. I think my next step will be to move into the dungeon: draw a new map and darker, dungeon-like textures (9918A colors makes that very hard). I'm considering if changing the texture size from 16x64 to 32x64 would make any difference? They still have to be displayed in the same 64x192 mode, but it could be worth it for the close-ups. On the other hand, small details would may be missed at long range. The exciting thing about this project is that for once I'm not bound by the number of sprites in a row or the number of patterns in the pattern table. I can add hundreds of textures to SAMS without running out of space. texcaster.rpk texcaster8.bin

It would be interesting to try to use the double buffering of the color table for some vector graphics: Draw to a 4K buffer in CPU RAM, copy updated sections to VDP, and flip the buffers.

Yes they are scrolled, but that is by changing the name table only. Actually I wasn't using this technique for double buffering but as a way to double the number of available characters. The double buffering is on the name table.

Are you suggesting to solve the problem by solving it somewhere else? 🙂

How about: mov @gstat,r12 andi r12,>2000 Or is [the value of] r12 used somewhere else?

I thought about using the technique you describe for the textured raycaster, but since the frame rate is low and the screen update is relatively fast I don't think it's worth the trouble. This demo was using the opposite technique. The colors are the same across the screen and the lower 2/3 patterns are double buffered. The stars at the top are sprites.

In this case there is a generic solution, it's just not faster for small numbers of bytes, and the speed also depends on odd/even issue. If you know at compile time that you only need to copy a small number of bytes you shouldn't call the generic routine. But if you don't know, the speed gained at the high end is likely to outweigh the speed loss at the low end.

I don't know if it's faster, but you can extend the sign using sra r0,8. Then you don't need clr, jgt, ori or swpb.

If you write the page number to all the pages you want to test first, e.g. 255, 127, 63, 31, and then check that the values are still there in a second loop, it should work.