Jump to content

Recommended Posts

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 

Share this post


Link to post
Share on other sites
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 by artrag

Share this post


Link to post
Share on other sites
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.

  • Like 1

Share this post


Link to post
Share on other sites

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 

 

image.png.7676f55dcf14c98082a237074d230e07.png

 

 

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

index.php?PHPSESSID=oageqqu65m2r7rpb5c01

 

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

 

132664.png?updated=1590385821

 

 

 

Edited by artrag
  • Like 2

Share this post


Link to post
Share on other sites
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.

  • Like 2

Share this post


Link to post
Share on other sites
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?

B4kjzfcCIAARAom?format=jpg&name=large

 

  • Like 1

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

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 by artrag
fixed bugs, improved comments
  • Like 1

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...