Raycaster

[artrag]

4 hours ago, Asmusr said:

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.

Humm, in this case maybe further optimizations on sprite plotting could be not really needed 

[artrag]

On 10/17/2020 at 4:13 PM, Asmusr said:

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). 

 

Is the difference due to the need to mask the nibble of the "other" column already filled by the wall?

If this is the problem, you could plot two pixels at time if both wall columns have a distance bigger than the sprite and limit the slow code to the case when the sprite is occluding one column and not the other.

 

I was suggesting to have an unrolled routine for each scale able to plot the full height of the texture (64 pixels zoomed up to the max scale).

Entering in one of those routines at an intermediate point would allow you to plot a run of N points (<64) at the selected scale.

The sequence to be scaled depends on the value of the register pointing to the data, the number of pixel on the screen depends on the entry point in the code.

You should probably customise the code for left and right nibble, doubling the amount of code.

 

You can encode a column of texture as a sequence of runs of non transparent pixels, each run with its offset (in 0-63) and its length (in 0-63) in its header.

You should probably store the same sequence of runs of non transparent pixels twice, on the two different nibbles to deal with odd and even columns

 

In order to plot a run of pixels at a given scale:

- choose the routine for that scale

- set the register pointing to the destination of the data in the video buffer according to offset x scale

- set the register pointing to the source  of the data to the run of bytes

- chose an entry point according to run length x scale

 

Anyway, if you aim to a RPG, maybe the effort is not worth 

 

 

Edited October 21, 2020 by artrag

[LASooner]

11 hours ago, Asmusr said:

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.

Just make the game where you're a plumber fighting creatures in the sewer, worked for Nintendo.  You have to fight the creatures as you fix broken pipes.

[artrag]

About the setting there is a roguelike called Xenomarine 

Link to animated sprites

Maybe a space setting with alien monsters can fit better with the TMS9918 palette 

This is a picture with some monsters

Sadly the sprites cannot be reused as they are top down 

 

 

 

This is something front view, fitting the size you need, but with a wrong palette

 

I'll try to find something else closer to the TMS9918 palette 

 

About for color mismatch, maybe Corridor 7 sprites can be a better reference, but they are 64x64 and need to be rescaled in 32x64

 

 

 

 

Edited October 18, 2020 by artrag

[fabrice montupet]

21 hours ago, Asmusr said:

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.

An kind of RPG game, that's fine !

Just hope that the game will not be too much gore/creepy/bloody.

[artrag]

2 hours ago, fabrice montupet said:

An kind of RPG game, that's fine !

Just hope that the game will not be too much gore/creepy/bloody.

like this?

 

[jrhodes]

It would be fun to have something like Swords and Serpents for the NES on the TI.

[Asmusr]

On 10/18/2020 at 12:55 AM, artrag said:

- chose an entry point according to run length x scale

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.

[artrag]

I see the problem but I was thinking to scales >1, where you have to plot plenty of pixels 

 

 

Texture height: 64
Run height in texture pixels: 5
Scaled sprite height on screen: 192

Size of the unrolled code (for scale 192) : 869 bytes (? just a guess)

 

Number of scaled pixels to draw = 5/64*192 = 15

Entry point wrt the label where the code starts = 869 - 15*(869/64) = 665

 

so if you say label192 the start of the unrolled code for plotting 64 pixels as zoomed to 192 pixels, if you jump to label192 + 665 you should plot only 15 pixels in the zoomed scale, corresponding to 5 pixels in the texture size.

 

The real issue is that one should avoid jumping in the middle of  an instruction...

 

A possible strategy could be to define 64 entry points into the unrolled code and jump accordingly to a jump table and to the run length

You should add a table of 64 entry points to each unrolled routine, one per scale

In the above example where we have "Run height in texture pixels: 5", you should pick the entry point in the table corresponding to the plotting of the last 5 pixels scaled

 

I expect your code could be something like this (scale 192)

 

label192E64: unrolled code for one pixel from source_register to destination_register

label192E63: unrolled code for one pixel from source_register to destination_register

label192E62: unrolled code for one pixel from source_register to destination_register

                  [...]

label192E5: unrolled code for one pixel from source_register to destination_register

label192E4: unrolled code for one pixel from source_register to destination_register

label192E3: unrolled code for one pixel from source_register to destination_register

                  [...]

                  return

 

Jumptable192: DW label192E1,label192E2,label192E3,label192E4,label192E5,label192E6,label192E7,...,label192E64

 

idealized_jump_according_run_length:

 

 

               reg1= run_length 

               reg1 = reg1 + Jumptable192                    ; assuming word count

               reg2 = *(reg1)                                        ; valued pointed by reg1

               set_up_destination_register according to offset and scale        ; it should be  offset * 192/64

               set_up_source_register according to run address                    

               call reg2

              [...]

 

         

It should work also for scales <1, probably having many labels aiming to instructions for skipping pixels in the texture run

 

Edited October 21, 2020 by artrag
fixed bugs, improved comments

[Asmusr]

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

Edited October 30, 2020 by Asmusr

[Omega-TI]

Oh yeah!  Thanks man!  I just downloaded this puppy and am gonna test it right NOW!

 

[fabrice montupet]

That's great!

[Tursi]

Looking fantastic

 

[artrag]

The speed is excellent!  Any new optimization or just the smaller view port?

Ps

There are the flat walls that sometimes you can pass as they were doors. Are they going to be secret passages?

Enemy sprites sometimes seem to pass walls.

[Asmusr]

4 hours ago, artrag said:

The speed is excellent!  Any new optimization or just the smaller view port?

Ps

There are the flat walls that sometimes you can pass as they were doors. Are they going to be secret passages?

Enemy sprites sometimes seem to pass walls.

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?

 

[+OLD CS1]

1 hour ago, Asmusr said:

They are currently moving much more fine grained than the player, but maybe they should also jump from square to square?

I do not see this as a problem.  The slightly more fluid motion adds to the environment, at least an element of more realistic movement and maybe a little more relief or anxiety when faced against an enemy.  Ultimately I expect it will depend upon how performance is affected.

[fabrice montupet]

Rasmus, do you plan to enlarge the size of the map to me more visible?

[artrag]

Actually if the performance stays good I prefer to have smooth movements for enemies. It also depends on what kind of interaction you want between them and the player and on the kind of animation you can want to implement 

[Omega-TI]

Anything new on this?

[Asmusr]

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.

 

[Asmusr]

Latest video:

 

texcaster.rpk texcaster8.bin

[Elia Spallanzani fdt]

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?

[Asmusr]

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?

[+arcadeshopper]

How would you move with the mouse then?

You could click on the edges of the screen top right left bottom of the game display

Sent from my LM-V600 using Tapatalk

[Asmusr]

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