Asmusr

Yes, it reserves one byte. No, because DATA always reserves 2 bytes even though the value 1 could be stored in one byte. I'm not actually sure under which circumstance the assembler automatically aligns to an even address. I think Win99Asm is doing it differently from the E/A assembler.

Here is the source code and a link to the original post. Yes it's much the same technique as the hat demo except that hat demo is bitmap mode. decoder.a99

I have checked the code of the roto-zoom demo, and it's basically just updating the whole name table and a set of character patterns each frame with data pre-calculated on a PC, so the TI code is not very exciting. It would probably be more interesting to look at the code for the megademo or some of the other demos I have posted over time. I found a few of them in this forum by searching for 'demo' in the title. https://github.com/Rasmus-M/ti99demo

I think you have much better control over the video timing on the C64, so they can change the colors several times each scanline. On the TI-99/4A the only way to find out which part of the screen in being drawn is to place five sprites on a row and poll the VDP status register until the 5th sprite flag is set. That would be far too slow for something like the C64 demo, but it was used in the megadome for several of the effects. Here is something slightly similar I did on the TI using a complete different technique. This is more like a compressed animation.

You need to open the file before you write to it. I see now that you did open it.

That should be PAB+9, not PAB+48.

You need to update the buffer address in the PAB every time you write a new record.

A browser cannot load any files from you local drive without the explicit consent of the user. So either you have to use the version of RXB under Software/Apps or you have to use an rpk version. That's why rpk is the superior format. If we could agree on zipped files with the naming convention that would also be fine.

The way it works now is that every time you move or turn it redraws everything. When you stand still it doesn't cast rays and it only redraws columns where a sprite has appeared. That lasts until you move again and the redraw flags on the columns are reset. I'm counting the number of interrupts and insert a delay if it's going too fast. One optimization I did is to remove the counter for max distance from the inner ray casting loop. That is no longer needed since we are indoors and we always hit a wall within a short distance. The secret passages are currently implemented by setting a bit weight 1 on the map value. For some reason I haven't implemented that for textured blocks yet, but the plan is that all blocks can be a secret passage. I'm thinking of removing the untextured blocks since they are no longer faster and only complicate the code. I haven't noticed that sprites pass through walls, but they can be drawn partly inside a wall. They are currently moving much more fine grained than the player, but maybe they should also jump from square to square?

Yes I think that would be possible. It would sound different, of course, from how it sounds on a PC. I noticed that Windows Media Player doesn't play the percussion track.

I have taken the first steps towards a point and click interface where you move the pointer with the joystick. I know that various mouse solutions exist, including TIPI, but since I don't have any of those this is how it will work (for now at least). You can also use the keyboard to move (Q, W, E, S), fire (SPACE), and strafe (A, D). I have reduced the 3D screen size by 4 rows (32 pixels) to make room for the bottom panel. It has a small positive effect on performance and the side effect that each block is a square. Most of the icons at the bottom are just for show, but the scroll icon opens the map and the sword icon triggers fire. You can also open doors by clicking on them, which shows how you can interact with the map. This will also be used to click on secret buttons etc. texcaster8.bin raycaster.rpk

There was a game called TIX. It didn't quite hit the target, so I abandoned it.

You could use GROMCFG on the TI.

My game Fork is using early clock all the time a lot. fork8.bin

https://js99er.net works quite well on a phone, but you need tiny fingers to access the keyboard.

Yes on the CPC you could choose 2, 4, or 16 colours (depending on the mode) from the bigger palette of 27. That was really advanced for its time. The F18A can do much more, of course, which is why a started this topic. If we had a better but compatible palette, it would be simple to allow F18A owners to choose that in a game without changing the graphics.

JS99er should work directly with controllers compatible with the Gamepad API. I think mine is an Xbox controller. https://developer.mozilla.org/en-US/docs/Web/API/Gamepad_API/Using_the_Gamepad_API

That's what I'm not clear about. For example: Texture height: 64 Run height in texture pixels: 5 Sprite height on screen: 38 Size of unrolled code (height=38) in bytes: 172 Fraction of code to run: 5/64 = 0.078125 Number of bytes to run: 0.078125 * 172 = 13.4375 Number of screen pixels drawn: 0.078125 * 38 = 2.96875 Clearly we cannot execute 13.4375 bytes or draw 2.96875 pixels, so I think the encoding routine would need to keep track of these fractions for us, and tell us exactly where to call the code (or how many screen bytes to skip), at a given scale.

It was my plan to do something medieval and dungeon like, but since the color palette makes that difficult my current plan is to do something 'abandoned tech'/sewer like. The current selection of monsters doesn't really comply with that, so if I don't want to draw them I need to look for a another source. The current weapon you could think of as a thrown rock, which should apply to any setting, but really the whole thing is up for debate - also the way of controlling the game, which could be changed to 'mouse pointer' style. Maybe I should reserve some screen space for status information, and maybe the game should be turn based? The only thing that's clear is that this is not a first person shooter but more like an RPG. I'm not going to update the non-textured FPS any further.

I did it, and I think the result is worth the reduced frame rate in some places. The floor/ceiling now takes up half of the 512K ROM, but it could be compressed and uncompressed to SAMS. texcaster.rpk texcaster8.bin

Yes it is quite confusing to have two discussions taking place at the same time. 🙂

If you're talking about a raycaster it cannot draw anything with holes or anything with variable heights.

The reason it will never happen is not the hardware requirements but because it would take thousands of hours to develop.

Unfortunately it cannot be the same code as for the walls because it takes one instruction to draw a wall pixel but two to draw a sprite pixel. On the other hand the sprite code is the same for even and odd columns. Are you suggesting to encode this once per texture or once per texture and scale? If it's once per texture it appears to require some quite complex calculations to decide where to call the code and what the source and destination addresses should be set to. If it's once texture and scale it appears to require a lot of space (something like 32K per texture).

The textures are currently 32x64, but reducing the height to 32 would in itself reduce the overhead for handling empty pixels by a factor 2 for heights where you need to read all the texture pixels, i.e. >= 32.