Astonishing and enigmatic pics from BatmanGroup!!

[XeNoMoRPH]

Never seen this 

[Puresox]

nice

[Rhino]

Thanks for the feedback!

@ervin
Currently the inertia is where you can see that the scroll has pixel precision, since the "standar" speed of the player is more than one pixel.

@Morri
That is the idea, publish the engine when finished so other developers can use it.

@Carnivius
Thanks for the offer! I hope we can do something together, but I have to finish Pinball Dreams first.
I would also like to do an extended version of the engine for 128kb with multidirectional scroll, so that it can cover more game types. It can also work at 25 or 17 fps, etc... to use more and biggest sprites at once on screen. I remember great Amiga games that do not run at 50fps, Gods for example, that could have a similar performance on CPC.

[Carnivius]

Thanks for the offer! I hope we can do something together, but I have to finish Pinball Dreams first.
I would also like to do an extended version of the engine for 128kb with multidirectional scroll, so that it can cover more game types. It can also work at 25 or 17 fps, etc... to use more and biggest sprites at once on screen. I remember great Amiga games that do not run at 50fps, Gods for example, that could have a similar performance on CPC.

Of course I'd like to see Pinball Dreams finished as soon as possible.  It's looking great.
There's no rush on my projects.  Just that seeing this has me rethinking the frame rates, sprite movement speeds and scrolling of all the CPC-projects I've been designing  like when I've been making the PC 'mock up' prototype things of the games I've been purposely running them at a slower frame rate like 17 or so and scrolling in lots of 2 mode 0 pixels.. and most of them are simple left and right two way scrolling things anyways like the RoboCop fan-sequel. This demo has me thinking that amazingly they don't actually need to run that chunky at all.  I stil don't get how you've done it when so many CPC games haven't.  Where was this in the 80s? 

[Puresox]

It would be great to have the talented programmers Names listed with a paypal link somewhere prominent on the Wiki. So people can show there appreciation at ease.
Some great work goes on that pushes the CPC scene forward. Especially with the information being shared. Even if it is just the odd quid from time to time.

[Rhino]

Of course I'd like to see Pinball Dreams finished as soon as possible.  It's looking great.
There's no rush on my projects.  Just that seeing this has me rethinking the frame rates, sprite movement speeds and scrolling of all the CPC-projects I've been designing  like when I've been making the PC 'mock up' prototype things of the games I've been purposely running them at a slower frame rate like 17 or so and scrolling in lots of 2 mode 0 pixels.. and most of them are simple left and right two way scrolling things anyways like the RoboCop fan-sequel. This demo has me thinking that amazingly they don't actually need to run that chunky at all.  I stil don't get how you've done it when so many CPC games haven't.  Where was this in the 80s? 

Thanks!
There is a very direct relation between fps and the amount and size of sprites required by a game,  so I think you've done well in estimating that speed if your games require a good amount/size of sprites. On the other hand, that is not a bad speed, almost all the Bitmap Brother's games on Amiga run at that speed or less.

But Amstrad can also make good scrolling games at 50 fps, and I mean games with a certain complexity. In part, it's something I try to show with Pinball Dreams. Which has had a great reception, but you can still see people from other platforms claim that CPC may be good for vertical pixel scroll but not for horizontal while it's a matter where the CPC still has a lot to say.

[Morri]

Thanks for the feedback!

@Morri
That is the idea, publish the engine when finished so other developers can use it.

Well, if you ever decide to make it accessible via BASIC, then I'm in! 

[Xyphoe]

Awesome!!!!!

Can't wait for this.

Done a quick YouTube video to help promote and spread the word for you...

[Joseman]

Awesome!!!!!

Can't wait for this.

Done a quick YouTube video to help promote and spread the word for you...

Keep an eye and take care on Nintendo and his IP's, i think that they don't like too much that mario enter on foreign machines 

[Puresox]

I expect if Nintendo got it involved it would be more beneficial than not tbh. A load of publicity , and then A quick ok we bow to your requests and alter name/graphics. They can hardly say jack if you're not making money from it? Surely?

[Sykobee (Briggsy)]

Nintendo crack down hard on this type of thing unfortunately.


Maybe an 8-bit computer mostly popular in Europe would stay under the radar for a while.


Probably better to keep the core game concepts but with different graphics and maps from the start.

[Carnivius]

oh is it an actual Mario game?  I thought it was just the Mario stuff just for testing so you get a good idea of what it can do. 

[Rhino]

Thanks for the video!

I'm not worried about Nintendo since Mario's theme has only been used for evaluation purposes of an engine demo. As commented in an earlier message, as far as I know, the first game that will use this engine is not planned to be a Mario conversion.

But, once the engine be published, any developer can use it to do Super Mario Bros or anything else. By the way, I think GinBlog82 is going ahead with its project of doing SMB on CPC, and I do not want to shadow his project.

http://www.cpcwiki.eu/forum/games/super-mario-bros-on-cpc-464-still-alive!/

[Joseman]

But, once the engine be published, any developer can use it to do Super Mario Bros or anything else. By the way, I think GinBlog82 is going ahead with its project of doing SMB on CPC, and I do not want to shadow his project.

http://www.cpcwiki.eu/forum/games/super-mario-bros-on-cpc-464-still-alive!/

Maybe he can use this engine with his SMB project? Can anyone contact and talk to him about this?

I don't know at what stage his project is, but if @GinBlog82 use this engine and other person(s) do the graphics (we have very good graphic designers around here) the SMB project can be finished!

What can we do to encourage people to help in this project to be finished??

[Xifos]

Sorry for the technical question but...
I suppose you're using crtc register 3 for byte horizontal hardware scrolling, but how do you manage mode 0 pixel scrolling ?
With preshifted buffers, but not using double buffering ?

Great demo anyway !

[Rhino]

Sorry for the technical question but...
I suppose you're using crtc register 3 for byte horizontal hardware scrolling, but how do you manage mode 0 pixel scrolling ?
With preshifted buffers, but not using double buffering ?

Great demo anyway !

Well, if nobody saw the trick without debugging the code, it worked fine

BTW, about Reg 3 scrolling, I noticed in my tests that it is more accurate on CRTC type 3 (exact half-character), in type 4 I have not tried but probably it is the same. In type 0 and 2 is not exactly half-character, but it is very close. And type 1 is where it most differs.
Can anyone else confirm this?

[pacomix]

Amazing!!! You rle each byte-column for drawing and use color for collisions (black?) or you actually use rle and tile-based (drawing only the affected column of the tile) for the scroll?


Enviado desde mi iPhone utilizando Tapatalk

[Rhino]

Amazing!!! You rle each byte-column for drawing and use color for collisions (black?) or you actually use rle and tile-based (drawing only the affected column of the tile) for the scroll?


Enviado desde mi iPhone utilizando Tapatalk

The tile map is compressed by columns and uses a decompression buffer.
This buffer is used to clear sprites and detect tile-level collisions. Between sprites it uses pixel precise bounding box for collisions.
When it scrolls enough, it draw a column of tiles, but do not draw all the tiles in the column, but only those that have changed with respect to the residual tiles that appear in that column.
Another optimization is that if a sprite has empty background tiles, it draw the sprite without mask. This optimization is optional and only efficient if there is a predominance of empty tiles in the background, as is often in SMB

[jesusdelmas]

The tile map is compressed by columns and uses a decompression buffer.
This buffer is used to clear sprites and detect tile-level collisions. Between sprites it uses pixel precise bounding box for collisions.
When it scrolls enough, it draw a column of tiles, but do not draw all the tiles in the column, but only those that have changed with respect to the residual tiles that appear in that column.
Another optimization is that if a sprite has empty background tiles, it draw the sprite without mask. This optimization is optional and only efficient if there is a predominance of empty tiles in the background, as is often in SMB

Amazing job Rhino,the engine looks fantastic, bot i supose that it will work only in a cpc6128 and not in a cpc464, or it will work on both?

[Rhino]

Amazing job Rhino,the engine looks fantastic, bot i supose that it will work only in a cpc6128 and not in a cpc464, or it will work on both?

Thanks! It works on 64kb, but there are only 24kb free for the game due to the double buffer of the large screen, so 128kb would be more appropriate for large games. It is also possible to use dynamic loading to have more memory.

[GinBlog82]

Maybe he can use this engine with his SMB project? Can anyone contact and talk to him about this?


I don't know at what stage his project is, but if @GinBlog82 use this engine and other person(s) do the graphics (we have very good graphic designers around here) the SMB project can be finished!


What can we do to encourage people to help in this project to be finished??

Hi, sorry for the delay. I was so full with my actual job (I work for AWS as SDE2, so pretty busy) that I didn't touch my project at all (sorry). Searching on youtube, I recently discovered this demo and I was wondering how much the cpcwiki community was blaming me for my poor attempt in cloning SMB so far :-) However I'm still satisfied with my old result, because I believe that they are two different kind of projects, with two different kind of results.


From my point of view, I wanted to reproduce the old SMB graphics without modifying the original tileset (same pixel resolution). In the Rhino's demo, instead, I see that the graphics has been readapted for mode 0 and overscan, that is more useful as skin to show his engine's features but not exactly what I was trying to do in the past. Using mode 0 instead of mode 1 is better if you want to get smoother scrolling with less resolution and more colors, it's something that I already evaluated in the past but I don't think that I'll go in that direction now. About the demo, the useful part of the screen is about 384x160, so I'd say 24x10 tiles on mode 0, mine was 16x12 on mode 1 (more compatibile with the famous World 1-1 map). Playing with Mario all around, the physics looks pretty different than the original title (I guess because it's an early demo). If you move forward or backward it goes immediately without any kind of acceleration or friction, which is a simplification too. I'm not saying that adding the old mario physics is something complicated, but it adds complexity to the code and it may introduce concerns, in particular if you are dealing with CRTC registers and you may end up with sync issues, so you must be careful.


Anyway, the Rhino's demo is amazing and it has some interesting ideas from what I can learn to improve my demo and achieve a smoother scrolling by myself. I'm not going to throw away my work to use other people engines (or disasm them), even if I don't have time to develop, so don't ask me to do it because the answer will be always a big "NO" :-) I think that the scrolling is something that you can always improve since you are alive, throwing the old technique away and try new solutions, so I'm not concerned because there is no limit on something that you may learn and implement. Maybe a good idea is to use a larger screen to cover borders and play more with the CRTC registers. Thank you very much for the suggestions and for the inspiration that you gave to me so far.

[Rhino]

Hi, sorry for the delay. I was so full with my actual job (I work for AWS as SDE2, so pretty busy) that I didn't touch my project at all (sorry). Searching on youtube, I recently discovered this demo and I was wondering how much the cpcwiki community was blaming me for my poor attempt in cloning SMB so far :-) However I'm still satisfied with my old result, because I believe that they are two different kind of projects, with two different kind of results.


From my point of view, I wanted to reproduce the old SMB graphics without modifying the original tileset (same pixel resolution). In the Rhino's demo, instead, I see that the graphics has been readapted for mode 0 and overscan, that is more useful as skin to show his engine's features but not exactly what I was trying to do in the past. Using mode 0 instead of mode 1 is better if you want to get smoother scrolling with less resolution and more colors, it's something that I already evaluated in the past but I don't think that I'll go in that direction now. About the demo, the useful part of the screen is about 384x160, so I'd say 24x10 tiles on mode 0, mine was 16x12 on mode 1 (more compatibile with the famous World 1-1 map). Playing with Mario all around, the physics looks pretty different than the original title (I guess because it's an early demo). If you move forward or backward it goes immediately without any kind of acceleration or friction, which is a simplification too. I'm not saying that adding the old mario physics is something complicated, but it adds complexity to the code and it may introduce concerns, in particular if you are dealing with CRTC registers and you may end up with sync issues, so you must be careful.


Anyway, the Rhino's demo is amazing and it has some interesting ideas from what I can learn to improve my demo and achieve a smoother scrolling by myself. I'm not going to throw away my work to use other people engines (or disasm them), even if I don't have time to develop, so don't ask me to do it because the answer will be always a big "NO" :-) I think that the scrolling is something that you can always improve since you are alive, throwing the old technique away and try new solutions, so I'm not concerned because there is no limit on something that you may learn and implement. Maybe a good idea is to use a larger screen to cover borders and play more with the CRTC registers. Thank you very much for the suggestions and for the inspiration that you gave to me so far.

Hi GinBlog82,

I hope you can continue with SMB soon. You're doing a great job!

You are right about there are great differences between SMB physics and the one in this demo, since it is not an attempt of faithful port the original. However, this example includes a bit of inertia, acceleration and deceleration in Mario's movement to show the 50fps pixel-precise scroll feature.

Regards!

[GinBlog82]

Thanks. Yesterday I found some time to continue the project. I implemented the scrolling with CRTC R3 (4 pixels on mode 1) and solved some sync issues, the result is better than I expected. The only problem is with the borders, that are flickering during the scrolling because I'm not covering them. I'm not so sure if I want to sacrifice 2 rows of tiles to go full 24x10 and cover that borders. I eliminated the code that preserved the background from sprite pixels because it was slow, instead of that I'm drawing with a xor that I want to replace with an actual mask as soon as possible. Maybe the next step could be to have finer scrolling using two buffers, but before that I want to achieve a robust result to make a new video on youtube.

[tjohnson]

Thanks. Yesterday I found some time to continue the project. I implemented the scrolling with CRTC R3 (4 pixels on mode 1) and solved some sync issues, the result is better than I expected. The only problem is with the borders, that are flickering during the scrolling because I'm not covering them. I'm not so sure if I want to sacrifice 2 rows of tiles to go full 24x10 and cover that borders. I eliminated the code that preserved the background from sprite pixels because it was slow, instead of that I'm drawing with a xor that I want to replace with an actual mask as soon as possible. Maybe the next step could be to have finer scrolling using two buffers, but before that I want to achieve a robust result to make a new video on youtube.

Hey GinBlog82 any chance of a youtube video, would be good to see your current progress on this!

[jesusdelmas]

Thanks! It works on 64kb, but there are only 24kb free for the game due to the double buffer of the large screen, so 128kb would be more appropriate for large games. It is also possible to use dynamic loading to have more memory.

Awesome! you are right, with only 24 kb free it woould be a short game, but a 464 versión is always welcome . Amacing job anyway Rhino, cant wait for a game with the final version of the engine,