Super mario bros on CPC 464, still alive!

[TotO]

If you have a GeForce graphics card, you can use GeForce NVIDIA Experience, the best video capture software I ever used so far. It implements something similar to NVIDIA GRID technology on kepler/maxwell hardware, so the lag is totally absent.

So, the big scroll problem shown on your video is due to the CPC program and not the video? 

[Rhino]

My latest efforts, I wish that you like it:

[youtube]https://www.youtube.com/watch?v=AuhphRNWy6M[/youtube]

It's pretty fast and easy to control, I'm pretty happy with the responsiveness and the overall result. The next step is to add enemies and bonus, make the level playable.

Nice!
One idea, have you thought about using a wider screen to hide the effects of the scroll at the borders?

[GinBlog82]

Nice!
One idea, have you thought about using a wider screen to hide the effects of the scroll at the borders?

Yes, it's an early demo and it can be improved.

So, the big scroll problem shown on your video is due to the CPC program and not the video? 

Consider that I cannot use a double buffer anymore (lack of memory) so the problems related to front buffer and tearing will be present and limited as best as I can,
considering the moving pixels. About the scroll, it uses now the CRTC register 3 instead of register 12 of the previous video, that is pretty hard to sync. Maybe a better
syncronization with the vertical blank would solve this problem. Winape is pretty honest about it and simulates the CRT glitch, surely I have to solve it or if it looks bad,
maybe disable it and eventually go for 8 pixels accuracy? Let's see.

[Dizrythmia]

I'm very impressed with how the sprite movement almost accurately mirrors the original NES version. Scrolling is an issue, but as you said, this is a very early version of the game.


I'm a bit worried with the game showing up on websites as a work in progress. This is normally the time most projects like this die thanks to Nintendo sending out C&Ds. I'm sure they're on hold to their lawyers right now...

[GinBlog82]

I'm a bit worried with the game showing up on websites as a work in progress. This is normally the time most projects like this die thanks to Nintendo sending out C&Ds. I'm sure they're on hold to their lawyers right now...

Well, maybe a good strategy is to not make too much rumors and release the game months (maybe years?) after the youtube videos. Currently, the video is already known as SMB / Nintendo related and it's an experiment,
like hundreds of other youtube videos. I'm sure that they already know about it and that they are not concerned because it's "retro-gaming stuff", otherwise I would have received the email from the lawyers about 1 year ago.
If I don't want to make money from it or to steal from the Nintendo the possibility to make money, they have no reason to pay lawyers to make me stop, and in the form of youtube videos it's like free advertising or something
like that, something that everybody can do. Even the Nintendo cannot make money selling SMB for the CPC 464 or Spectrum ZX or Commodore 64 in 2016, so they don't have any reason to stop the project, or maybe
they are crazy and they will, but why they don't remove all the Spectrum ZX videos or other SMB related materials on the internet? There are people on youtube with videos where they play smb or where they show mods
for GTA 5, Unreal Engine 4, Minecraft, or remakes for old platforms like Amiga, Commodore 64, Spectrum ZX, or flash animations, hand-drawing, flip-books, plasticine, legos, parodies, spin offs, and thousand of materials
protected by copyrights that are used to create free entertainment just for fun. It's different from creating a clone of Mario 64 for PC, Android, XBox360, because in this way you are stealing from Nintendo the chance to make
money on these platforms or to avoid a bad market strategy if they want to continue selling modern hardware along one killer-application product based on Mario, like they always did. At least, it is what I think about it, when
they'll contact me to stop the project, I will do it without problems because I'm not making money from it and I can switch to other projects. The most important thing is that SMB was a good chance to improve my skills as
computer programmer and taught me how to make games on old computers, that in a world where everybody need gigabytes to make also the simpliest things, it's a unique skill and something that I will do again in the
future.

[GinBlog82]

So, the big scroll problem shown on your video is due to the CPC program and not the video? 

Nice!
One idea, have you thought about using a wider screen to hide the effects of the scroll at the borders?

Today I fixed it, a wider screen wasn't necessary.

[GinBlog82]

New video!


https://www.youtube.com/watch?v=6WMwSLEMHk4

[Puresox]

Hey not bad , My only suggestion ,would be a tweak on the Pallet mix . Really feel it needs some contrasting colour to help it pop a little. Maybe a Red . Just my opinion but feel it appears a little subdued visually . Please don't think I'm bitching  on you . It definitely looks like improvements are being made with each vid.

[GinBlog82]

Today I implemented an algorithm to draw characters with an horizontal accuracy of 1 pixels, now the movements are smooth like on the NES.

[Shaun M. Neary]

Hey not bad , My only suggestion ,would be a tweak on the Pallet mix . Really feel it needs some contrasting colour to help it pop a little. Maybe a Red . Just my opinion but feel it appears a little subdued visually . Please don't think I'm bitching  on you . It definitely looks like improvements are being made with each vid.

Was thinking the same. A shade of orange would work really well instead of grey.
Don't get me wrong, I think it looks outstanding so far, but the grey just brings it back to the stone age. But a palette change would improve the visuals tenfold.


Keep it up though, would love to see how this looks finished. =)

[GinBlog82]

Hey not bad , My only suggestion ,would be a tweak on the Pallet mix . Really feel it needs some contrasting colour to help it pop a little. Maybe a Red . Just my opinion but feel it appears a little subdued visually . Please don't think I'm bitching  on you . It definitely looks like improvements are being made with each vid.

What about this?

[Puresox]

I think that improves it massively . It really looks more inviting imo

[TotO]

Using two or tree palettes, depending the levels...
(orange should look better here)

[||C|-|E||]

What about this?

It think that it already looks much better! 

[Xifos]

I think you're doing good.
The hardware scrolling looks fine.
Good choice of colors in mode 1.
 

I'm interested in your sprite routine.
How do you manage to restore background and avoid flickering ?

[Nich]

What about this?

This choice of colours looks much more appealing to me!

[Puresox]

With those colours, this game is really looking close to the genuine article .Really promising work .

[GinBlog82]

With those colours, this game is really looking close to the genuine article .Really promising work .

To make you understand how close it's now to the original, I took this picture:

[Puresox]

Considering the limitations you have to deal with , it's darn impressive!
Even with the pipe not being green, it doesn't look out of place, imo.

[keith56]

Just watched the latest youtube vid.
Really impressive! even though its a WIP , it really has the "Mario Feel" of appearence and movement

The 4 colours don't take anything away from it either - and I think the Mode 1 keeps the sprites looking like the original

Excellent stuff!

[GinBlog82]

Just watched the latest youtube vid.
Really impressive! even though its a WIP , it really has the "Mario Feel" of appearence and movement

The 4 colours don't take anything away from it either - and I think the Mode 1 keeps the sprites looking like the original

Excellent stuff!

Thank you all. The lastest youtube video shows "only" the character with an horizontal accuracy of 4 pixels, then I decided to spend a
little bit of time implementing movements that are 1 pixel accurate. The "Mario feel" has been improved, now you have the feeling of
playing the NES title. The jump, the run, the collisions, I wanted everything to be perfect. The next step is to add the mashroom, coins
and enemies. Then I will implement a simple but effective algorithm to compress/decompress the levels, I want to put all the 16 levels
into a unique file loaded just once. When the game will be complete, you can put it into an old audio cassette and play it with your Amstrad
CPC 464 :-)

[Puresox]

Yeah , the temptation to have done it in mode 0,Must have been high. If I were to hear it being suggested before the project started I probably would have imagined an awful port , never was a massive fan of Mode 1, although there were definite exceptions.
 I mean when you think of Mario games ,you think of big bold colourful worlds . It seems a perfect fit Mode 0 . To manage to translate in Mode 1 is great . Whether the addition of enemy Sprites and ,Mushroom /Star Bonus's makes things awkward time will tell

[keith56]

I am quite curious in this project, as I am also developing a Mode 1 game, but the methods you are using are very different to mine... it makes me wonder if I'm doing things wrong 


I understand you're effecting a scroll by using the CRTC registers? so the screen data stays in the same place, but the display draws it from a different "Start point?" - I knew this was common for V scroll, but didn't realise it worked Horizontally... guess I need to re-read the tech docs on that one 


The 1 pixel accurate sprites  is also interesting , I tried this (I was playing with screen scrolling at the time), but gave up on it assuming it would be too slow... I do a "Per 2 pixel" sprite , but I cheat and store a second "Pre shifted" sprite 


I'm using Two screen buffers, and redraw everything, which eats up the free memory - also my backgrounds are very simple, mostly a "Gradient" effect with a few token sprites placed here and there - I'm pretty sure that the methods I'm using would not work for the "Mario" style game you're doing.


Keep up the good work!

[GinBlog82]

I understand you're effecting a scroll by using the CRTC registers? so the screen data stays in the same place, but the display draws it from a different "Start point?" - I knew this was common for V scroll, but didn't realise it worked Horizontally... guess I need to re-read the tech docs on that one 

With CRTC registers you can change the screen buffer offset, that can be used for both horizontal or vertical scrolling. The most important thing is that the offset
can be changed. If you change only 1 char (8 pixels), the screen is going to move horizontally, otherwise if you move 32 chars (if the width is 256) the screen is
going to shift vertically. However, the technique is most used for vertical scrolling because in this particular case it is easier. If you move 1 scan line at once, you
don't have to deal with the vertical misalignment of the screen when the (offset % 32) is between 0 and 31, as you can see in this picture:






To fix the misalignment, you need to draw the column 8 pixels down when the scanline is exceeded and make sure that your column don't exceed the vertical limit of
the screen and in that case make the column loop vertically. As you can see from my videos, the trick works pretty well :-)

The 1 pixel accurate sprites  is also interesting , I tried this (I was playing with screen scrolling at the time), but gave up on it assuming it would be too slow... I do a "Per 2 pixel" sprite , but I cheat and store a second "Pre shifted" sprite 

My project will be open source when it will be finished one day, so I have no restraints to share with you part of the code. As a gift to science, here is the row loop of my code to draw 1 pixel accurate:

Code: [Select]

Position 0:


    _draw_tile_loop_row:
        LD A, (DE)
        LD (HL), A
       
        INC DE
        INC HL
       
        DJNZ _draw_tile_loop_row
       
Position 1:
       
    _draw_tile2_loop_row:
        PUSH HL
       
        LD H, C
       
        LD A, (DE)
        INC DE
       
        LD L, A
       
        AND A, #0x11
        SLA A
        SLA A
        SLA A
        LD C, A
       
        LD A, L
        SRA A
        AND A, #0x77
        OR A, H
       
        POP HL
       
        LD (HL), A
        INC HL
       
        DJNZ _draw_tile2_loop_row
       
Position 2:
       
    _draw_tile3_loop_row:
        PUSH HL
       
        LD H, C
       
        LD A, (DE)
        INC DE
       
        LD L, A
       
        AND A, #0x33
        SLA A
        SLA A
        LD C, A
       
        LD A, L
        SRA A
        SRA A
        AND A, #0x33
        OR A, H
       
        POP HL
       
        LD (HL), A
        INC HL
       
        DJNZ _draw_tile3_loop_row
       
Position 3:
       
    _draw_tile4_loop_row:
        PUSH HL
       
        LD H, C
       
        LD A, (DE)
        INC DE
       
        LD L, A
       
        AND A, #0x77
        SLA A
        LD C, A
       
        LD A, L
        SRA A
        SRA A
        SRA A
        AND A, #0x11
        OR A, H
       
        POP HL
       
        LD (HL), A
        INC HL
       
        DJNZ _draw_tile4_loop_row

As you can see, I shift and replace bit positions to move only 1 pixel at once.

I'm using Two screen buffers, and redraw everything, which eats up the free memory - also my backgrounds are very simple, mostly a "Gradient" effect with a few token sprites placed here and there - I'm pretty sure that the methods I'm using would not work for the "Mario" style game you're doing.

In the past I used two screen buffers, but it's not a technique that i suggest anymore for a 64 KB game as it consumes too much memory. There are many techniques to avoid the
blinking glitch or tearing of single buffered games, like scattered back buffers, update moving pixels, xor masks and so on. Anyway it must fit your needs, anyway if memory is not
your problem, you can use the double buffer as well.

[Shaun M. Neary]

Wow. One palette tweak made a world of difference. Nicely done.
Keep it up =)