Author Topic: Astonishing and enigmatic pics from BatmanGroup!!  (Read 7144 times)

0 Members and 1 Guest are viewing this topic.

Offline Rhino

  • CPC6128
  • ****
  • Posts: 167
  • Liked: 389
Re: Astonishing and enigmatic pics from BatmanGroup!!
« Reply #90 on: 21:09, 22 July 17 »
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?

Offline pacomix

  • CPC6128
  • ****
  • Posts: 156
  • Liked: 72
Re: Astonishing and enigmatic pics from BatmanGroup!!
« Reply #91 on: 02:01, 26 July 17 »
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

Offline Rhino

  • CPC6128
  • ****
  • Posts: 167
  • Liked: 389
Re: Astonishing and enigmatic pics from BatmanGroup!!
« Reply #92 on: 16:15, 26 July 17 »
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

Offline jesusdelmas

  • CPC464
  • **
  • Posts: 31
  • Country: es
  • Liked: 16
Re: Astonishing and enigmatic pics from BatmanGroup!!
« Reply #93 on: 05:24, 29 July 17 »
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?

Offline Rhino

  • CPC6128
  • ****
  • Posts: 167
  • Liked: 389
Re: Astonishing and enigmatic pics from BatmanGroup!!
« Reply #94 on: 02:43, 30 July 17 »

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.

Offline GinBlog82

  • CPC464
  • **
  • Posts: 25
  • Liked: 84
Re: Astonishing and enigmatic pics from BatmanGroup!!
« Reply #95 on: 12:21, 04 August 17 »



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.

Offline Rhino

  • CPC6128
  • ****
  • Posts: 167
  • Liked: 389
Re: Astonishing and enigmatic pics from BatmanGroup!!
« Reply #96 on: 13:52, 06 August 17 »



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!

Offline GinBlog82

  • CPC464
  • **
  • Posts: 25
  • Liked: 84
Re: Astonishing and enigmatic pics from BatmanGroup!!
« Reply #97 on: 20:53, 07 August 17 »

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.

Offline tjohnson

  • CPC6128
  • ****
  • Posts: 208
  • Country: gb
  • Liked: 32
Re: Astonishing and enigmatic pics from BatmanGroup!!
« Reply #98 on: 00:18, 21 August 17 »

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!

Offline jesusdelmas

  • CPC464
  • **
  • Posts: 31
  • Country: es
  • Liked: 16
Re: Astonishing and enigmatic pics from BatmanGroup!!
« Reply #99 on: 16:53, 14 September 17 »
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,