Raycaster

[Raycaster]

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:

 

 

[Raycaster]

6 minutes ago, Elia Spallanzani fdt said:

you can click on the compass.

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

[Raycaster]

2 minutes ago, LASooner said:

Are you planning on having the ground and sky change when you use the tree wall texture? It would feel like you were in a dark forest if the ceiling just went black and dirt grass textures were used for the ground.

Yes. Everything is experimental right now.

[Raphael]

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.

[Sierra's Space Quest on the TI!]

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?

[Raycaster]

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

[Raycaster]

37 minutes ago, Elia Spallanzani fdt said:

the mouse seems a bit too slow and maybe the compass could go in the place of the 6 arrows, which do not seem useful?

How would you move with the mouse then?

[Raycaster]

Latest video:

 

texcaster.rpk texcaster8.bin

[TI BASIC/TI EXTENDED BASIC Games that are worth to be compiled...]

24 minutes ago, tmop69 said:

A couple of new compiled games for the weekend

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?

[Raycaster]

3 hours ago, Omega-TI said:

Anything new on this?

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.

 

[1 Meg Super AMS Discussion Thread]

16 minutes ago, MikeV said:

Circuits are generally on or off. When SAMS memory is accessed, does the identical memory address (and its contents) in SAMS overwrite its counterpart in the 32K, or is the circuit (pathway) simply rerouted to its SAMS counterpart and the 32K address then ignored? What do the 'mappers' actually do?

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.

[Roto-zoom animation]

1 hour ago, whoami999ster said:

@Asmusr : no way to have an example of one frame from the demo? 

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.

[The 9918 "Rainbow Effect"]

6 hours ago, Tursi said:

While artifact colors work well on many systems, I think the TI's resolution is too low to make good use of it. Would love to be proven wrong!

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.

[Roto-zoom animation]

4 hours ago, whoami999ster said:

What is meant for double buffering ? 

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.

[Sierra's Space Quest on the TI!]

41 minutes ago, MikeV said:

Good to know. I have yet to stay alive long enough to determine much.

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

[TI-99/4A Megademo]

8 hours ago, whoami999ster said:

Thanks a lot Rasmus above all for your patience... 

just to get an idea ... how many "pictures" (frames) did you produced to get this animation and on average what as the "dimension" in bytes... 

If I well understood you did it with Magellan ... 

No way to have also the Magellan File? ... 

Thanks as usual

 

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.

[Sierra's Space Quest on the TI!]

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

[Sierra's Space Quest on the TI!]

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.

[Sierra's Space Quest on the TI!]

 

Aargh, there is a time limit too.

[How to detect PAL/NTSC machines]

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.

[How to detect PAL/NTSC machines]

Does compiling make the difference between NTSC and PAL bigger?

[TI-99/4A Megademo]

4 hours ago, whoami999ster said:

but normally the "graphics" should be in the source code right?

Yes if is was to be assembled as an E/A#5 file it would usually contain the graphics.

4 hours ago, whoami999ster said:

but even without the "graphics" do you think that assembly step will work ?

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.

4 hours ago, whoami999ster said:

would you like to describe high level your source code

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.

[TI-99/4A Megademo]

9 hours ago, whoami999ster said:

Thanks as usual Rasmus ... that's what I mean for sharing the knowledge! 

Do you mind if I will come back to you with some questions?

 

Have a nice day/night whatever you're placed 

 

....

in the mean time I tried to compile decoder.a99 with winasm99 but no no success ... undefined symbol for FRM2 and undefined opcode XORG

I had also debuged rotozoom8.bin but the disassembly is quite different from decoder.a99 

Maybe I'm missing something but I was not able to find in the source code the "graphic" part deinition ... where I'm doing wrong... 

maybe should be better to move the discussion to the Roto-zoom animation thread ? or email

 

thanks  

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.

 

[Assembly on the 99/4A]

4 minutes ago, BeeryMiller said:

Will the Program Counter on real hardware allow execution of code on an odd boundary?  I did not think it would allow that.

 

I know back when Geneve support was first added to MESS, I found one or two instructions that did not 'autocorrect' for an even boundary that then threw the emulated 9995 into executing code on an odd boundary.  On the real hardware, the very same code did not allow that to happen.

 

Beery

 

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

[Assembly on the 99/4A]

27 minutes ago, GDMike said:

Say what? You were just waiting for me to walk into this. Lol now this doesn't make sense to me...

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.