Shinobi Remaster - Released

[Mr. DVG]

Regarding the writing on the door, i have been thinking about it since yesterday. Two tiles are spent for the writing above the door... Which it cannot even mimic the original as the pixels are too big and few. So i am still thinking of removing them and allocate these two tiles as extra tiles for the ground.
They could help imitate the pseudo 3d proportion of the arcade : grass  is more sparse at the front, and thicker on the back.
So removing detail that the player sees for a second, the writing, we allocate to the ground, and give more detail, where the player is watching for the whole stage while playing.

Absolutely agree with this choice, better to take better care of the graphic aspects visible during the entire level, rather than a small thing that appears for an instant (and it wasn't much that not even in the original by Aplin).

P.S. - I am pleased to note that the use of the "useless" yellow, together with other shades, has given amazing results (with the due proportions the block of rock with the grass in the middle seems almost like the original arcade). 

[Fmtrx]

Greetings all,


Just a small update. The time has come to up the game. 64 tiles is very restricting when you want to depict 4 stages (one mission).

An idea came up to me today which is: why load before each mission a tileset of 64 tiles and restrict the variation of graphics?

Wouldn't be better to have a tileset of 64 tiles per stage ? So each stage has its own 64 tiles, and we can accomplish extreme precision in the quality of the remaster. The only side effect is that we need ~30-40 kb instead of 10 kb of extra disk space.

Currently the game loads chites4.bin - which is the tileset of mission 4, as it loads the first stage of mission 4.
The hack in the code  would modify the loader so  that the game loads chites41.bin (tileset of stage 1, mission4) when it loads 41.bin (stage 1 of mission4), then loads tileset of stage 2 which is the chites42.bin when it loads 42.bin (stage 2 level of mission 4) etc.

This results in higher graphic details that match the arcade almost 1:1. Textures can be the same with the arcade.
Let's see an example of the wall in mission 4:

As is the current situation, i cannot include these textures you see in the attached photos. The red wall textures allocated 4 tiles in the original, but it needs 15 tiles to match the arcade (!). So 64 tiles for 4 stages are not enough.
But if we had 64 tiles per stage, then we could do it. Even my cat approves it as you can see

I am not sure how difficult is to hack this, but i believe that it is the easiest workaround, and without breaking compatibility with 464 machine. I will keep you noted if someone can accomplish this hack.

If this hack is done, i promise you that this would be a game changer of what we initially thought of the limits of this remaster!

[sigh]

Your new tiles for that level looks nice.

The only side effect is that we need ~30-40 kb instead of 10 kb of extra disk space.

I am not sure how difficult is to hack this, but i believe that it is the easiest workaround, and without breaking compatibility with 464 machine.

I could be wrong here - but 30 - 40kb might be very tight for the stock 464, as that version doesn't even have sound which would of probably have cost 8 - 10kb in itself?

[Fmtrx]

thanks sigh.


Actually this method does not require more RAM. Before each stage of a mission it loads a specific tileset for this stage which takes 2kb.
When player goes to next stage, it loads the  tileset of the next stage and overwrites the previous tileset.
So during each stage we use the same 2kb of ram. Only the contents change from stage to stage.

The 38 kBs are the extra disk space for storage as we allocate 19 different tilesets one for each stage and not one for each mission.
This is not an issue. Almost all of us have installed an sd card solution, personally i am using the excellent m4board from duke.
But even without these, one could play it by using two disks, or use a higher density disk with Parados.

[Gryzor]

Indeed very nice looking. No wonder cat approves.

[Fmtrx]

Indeed very nice looking. No wonder cat approves.

Τhanks Gryzor. I am thinking of posting in Programming forum to search for anyone who could do the hack. I hope that I do not break any forum rules with this. the reason is that i believe that if i post here is less visible to programmers, than posting explicitly there, where i believe that some hardcore coders visit it often.

[Gryzor]

Go ahead. It's not programming at this point, but we don't hang anyone for cross-posting

[Mr. DVG]

Greetings all,


Just a small update. The time has come to up the game. 64 tiles is very restricting when you want to depict 4 stages (one mission).

An idea came up to me today which is: why load before each mission a tileset of 64 tiles and restrict the variation of graphics?

Wouldn't be better to have a tileset of 64 tiles per stage ? So each stage has its own 64 tiles, and we can accomplish extreme precision in the quality of the remaster. The only side effect is that we need ~30-40 kb instead of 10 kb of extra disk space.

Currently the game loads chites4.bin - which is the tileset of mission 4, as it loads the first stage of mission 4.
The hack in the code  would modify the loader so  that the game loads chites41.bin (tileset of stage 1, mission4) when it loads 41.bin (stage 1 of mission4), then loads tileset of stage 2 which is the chites42.bin when it loads 42.bin (stage 2 level of mission 4) etc.

This results in higher graphic details that match the arcade almost 1:1. Textures can be the same with the arcade.
Let's see an example of the wall in mission 4:

As is the current situation, i cannot include these textures you see in the attached photos. The red wall textures allocated 4 tiles in the original, but it needs 15 tiles to match the arcade (!). So 64 tiles for 4 stages are not enough.
But if we had 64 tiles per stage, then we could do it. Even my cat approves it as you can see

I am not sure how difficult is to hack this, but i believe that it is the easiest workaround, and without breaking compatibility with 464 machine. I will keep you noted if someone can accomplish this hack.

If this hack is done, i promise you that this would be a game changer of what we initially thought of the limits of this remaster!

I really admire the dedication that you are instilling in this project!

I can't help you on a technical level, but I am confident that, in light of the new technical considerations you have set out, this remaster will be something revolutionary and can be an inspiration for many other similar projects!

I repeat that there is really much to learn from the past, you have been able to take it back and improve it! An unprecedented experience that will bear fruit as soon as they are ripe!

Thanks again! 

[Fmtrx]

Really Mr DVG, it should be me that I should say thanks, for your kind words.
Each message of your i read, is a source of motivation for me and for the project and helps me considerably in continuing the work.
I really hope that a coder will be found to do this hack with the tilesets, and then .... the sky is the limit -
well 64 tiles PER STAGE is considered as the sky for me ! :-)
Looking forward seeing your wonderboy project, one of my favorite games in the arcades.

[Mr. DVG]

Really Mr DVG, it should be me that I should say thanks, for your kind words.
Each message of your i read, is a source of motivation for me and for the project and helps me considerably in continuing the work.
I really hope that a coder will be found to do this hack with the tilesets, and then .... the sky is the limit -
well 64 tiles PER STAGE is considered as the sky for me ! :-)
Looking forward seeing your wonderboy project, one of my favorite games in the arcades.

I am sure you will succeed!

For Wonderboy the project is not mine, but the good Benjamin Yoris, a very good graphic designer who did an excellent graphic conversion job directly from the arcade game, masterfully adapting it for the CPC! He only needs one programmer (who, as you know, are very few and are the ones who do the dirty work), but it seems that Abalore is available (or at least I hope so) to collaborate on the project, after completing his exceptional Slap Fight / Alcon! 

[Fmtrx]

The work is indeed dirty. I work as a software developer, and the burn i get during the working hours generate the need to draw some graphics several afternoons each week and let some steam out of my head
It is a shame that my experience in ASM is limited at an academic level  gained during several university classes in 8th semester in the lab with an 8085. I could study and get a grasp of it but the learning curve is steep comparing with other languages which describe algorithms and are closer to human logic. So it would take much time.

[Sykobee (Briggsy)]

I presume the map is stored at 1 byte per tile, 6 bits for the graphic data and perhaps 2 bits metadata (a bit to indicate it's solid/background, what else?), or maybe it's just memory limited to 64 tiles?

[Fmtrx]

I presume the map is stored at 1 byte per tile, 6 bits for the graphic data and perhaps 2 bits metadata (a bit to indicate it's solid/background, what else?), or maybe it's just memory limited to 64 tiles?

Yes, each tile is assigned a number corresponding to a byte. A test of inserting more than 64 tiles showed correctly generated numbers inside the XX.bin map file that tilesudio generated. Additional tiles were correctly indexed as  40h, 41h... ( No65, No66...) etc.


But the problem is - after a talk i had with Fano - that the available memory is exactly 4096 bytes, and they had put a guard in the code, by doing an AND with 111111; which has the effect of resetting the number that addresses the tiles after 63. So 65 becomes 1, 70 becomes 6 etc.


I am not sure that they keep info if the tile is solid  with the extra bit. I am saying this because i did an experiment of removing object that player collides, the brown box in level 1, and inserted other tiles. But the player kept colliding at these coordinates.

[Sykobee (Briggsy)]

Thanks - so it's just a memory issue for the tileset. I guess the game must be crammed in (If not, rearranging memory to free up more tilespace is possible, but difficult and fiddly.)
The level 'objects' (boxes/floor-height, enemies, etc) must be stored separately to the map - doesn't affect a reskin, but new maps would be a problem.

[Fmtrx]

Designing new maps, or modifying existing maps other than the artistic style is impossible with what we have now.
But regarding the number of tiles, there could be a solution with an easy hack from someone experienced in ASM.
The idea is to load before each stage a tileset that is specific to this stage. Next stage will load a new tileset at the same area of the previous tileset
overwriting its previous contents (previous tileset is not needed anymore). Thus RAM requirement is the same.
So we will be able to use 64 different tiles per stage which gives enough freedom to provide detailed graphics, and very close to arcade.
Currently the tileset of 64 tiles is per mission (which consists of 3-4 stages) which is restrictive.

[sigh]

But the problem is - after a talk i had with Fano - that the available memory is exactly 4096 bytes, and they had put a guard in the code, by doing an AND with 111111; which has the effect of resetting the number that addresses the tiles after 63. So 65 becomes 1, 70 becomes 6 etc.

What would be the reason for doing this? Is this because some of those same tiles are used in different missions?

[Fmtrx]

Sounds like a precaution, in order to avoid referencing addresses outside of the 64 tile limit. I suppose that the number of tile (0-63) inside the map file (XX.bin) was added to a specific address in order to create an absolute address that references the address of the tile inside the tilemap file (CHITESX.bin) which its contents are copied somewhere in ram.

So there is no way to corrupt the game if you provide a map file that addresses more than 64 tiles.

Another speculation would be that these highest two bits are assigned values specific with tile properties from somewhere inside the game.
For example  if tile no 5  ( 0000 0101 ) belongs to the brown box, in mission 1, then mark bit 7 as 1 to indicate collision properties : 0100 0101
so that game engine reads its property.
But in mission 2, the tile  No 5 could be a part of the sky, so the bit 7 should be modified to 0. So the same tile No becomes now : 0000 0101.

So they clear the highest 2 bits (7th and 8th bit)  in order to set them properly for these properties.

But these are just speculations. Only the original programmer knows how exactly this works, and unfortunately we will never know.

[Mr. DVG]

Sorry if I bring this discussion up high, but I wanted to know if there are updates on this project.

From what I understood "Fmtrx" was now well on the various changes to be made to the main program!

[Fmtrx]

Sorry if I bring this discussion up high, but I wanted to know if there are updates on this project.

From what I understood "Fmtrx" was now well on the various changes to be made to the main program!

hello DVG, unfortunately the project has been suspended.
An attempt in modifying the code in order to have each stage its own tileset, failed.
Perhaps it has to do that the code has various self modifications (?).
ASM is not my field, and i do not have time to become an expert at this period and fix this.
What we need here is an experienced person in ASM to give me a hand, but unfortunately there is no interest
for this project from others, or there is no availability from others.
It is a shame, because if we could pull this modification, the graphics would be greatly enhanced.
(I also i have designed new frames that are not utilized)

[Mr. DVG]

hello DVG, unfortunately the project has been suspended.
An attempt in modifying the code in order to have each stage its own tileset, failed.
Perhaps it has to do that the code has various self modifications (?).
ASM is not my field, and i do not have time to become an expert at this period and fix this.
What we need here is an experienced person in ASM to give me a hand, but unfortunately there is no interest
for this project from others, or there is no availability from others.
It is a shame, because if we could pull this modification, the graphics would be greatly enhanced.
(I also i have designed new frames that are not utilized)

I am very sorry to hear this, and it is a pity to suspend everything in this way (given the excellent results obtained so far).

Maybe a new update could be released with the changes that have been possible! I remember that you had run many bugfixes compared to the versions that have been released ...

For the rest, I hope in my heart that this project will not be permanently abandoned!

[Shaun M. Neary]

Just wanna say...Finally had a chance to play this tonight (between my work and the implications Covid-19 had) time has been tight to say the least.

I LOVED THIS!
Granted, I loved the Aplin original, but the colour of the backgrounds is definitely easier on my near 43 year old eyes.
The game somehow also manages to fix a bug on level 4-2 where about 2/3rds of the way, an enemy comes at you at lightning speed, and unless you time it right, there's no chance of getting past him!

Nice work.

[Fmtrx]

Hi Shaun,


Thank you for your kind words, i am happy that you liked it. I have invested many hours in this, and i am willing to invest more if someday someone manages to do the hack so that each stage has its own tileset so that we will be able to use more textures.(now it has one tileset per mission) Some private builds i have done with tilesets that are specific for each stage, make the game look like the arcade.

[Shaun M. Neary]

Hi Shaun,


Thank you for your kind words, i am happy that you liked it. I have invested many hours in this, and i am willing to invest more if someday someone manages to do the hack so that each stage has its own tileset so that we will be able to use more textures.(now it has one tileset per mission) Some private builds i have done with tilesets that are specific for each stage, make the game look like the arcade.

I'll give it another play through if another release comes out. Finished it on the second attempt (was very drunk on the first), but I've been able to finish that game blindfolded (not literally) for years now.

[Fmtrx]

This game had excellent gameplay. C64 may had a better framerate, but the cpc version is more enjoyable.
I learned this game first in the arcades during a summer, I think 1988,mastered it without shurikens in all stages except some bosses. Afterwards i went to the home version. What an excellent game in its time.