Login [Register]
Don't have an account? Register now to chat, post, use our tools, and much more.
Oiram is a Mario-like platformer for the CE:

Oiram Download: Download
Oiram Level Editor: Download


WHAT!!! That looks awesome! I wish I would stop being lazy and learn asm. Razz
Awesome Mateo! I just wish I had a CE to help you look for bugs!
OMG, this is awesome. I hope you make this project even bigger and port it to Prizm as well - I will be glad to help if I can programming it in C or at least test it if it is in something else.
Looks great Mateo! Is this being written is C or assembly? Will you be able to support different tilesets? I'd love a Super Mario World one.
Ivoah wrote:
Looks great Mateo! Is this being written is C or assembly? Will you be able to support different tilesets? I'd love a Super Mario World one.

Yes; it already can. Tilesets are stored in an AppVar. It's written in assembly; there's no way I could get the kind of speed I would want from C. But yes; the tilemapping engine has already been added to the C library, for future use I guess. Smile
Is tile data (e.g. solid) stored in the AppVar too?
Ivoah wrote:
Looks great Mateo! Is this being written is C or assembly? Will you be able to support different tilesets? I'd love a Super Mario World one.
I just assumed that it was ez80 assembly, but that's actually a really excellent question. This of course looks extremely exciting, and I think the idea to make it work with Super Mario 1.2 levelsets from the monochrome calculators is an excellent one. I hope you'll keep us posted as you go!
Looks awesome Mateo! Noone managed to create a releasable colour Mario for the CSE so here's hoping you can knock this one out for the CE!

The animated tiles are looking very nice, are you redrawing each frame? Also I was wondering what pixel-increment the scrolling in the video is showing? (1-pixel, 2-pixel etc?).

I was also wondering what screen mode you are operating in? 8bpp so you can double buffer?

Looking forward to seeing further updates Smile.
tr1p1ea wrote:
The animated tiles are looking very nice, are you redrawing each frame? Also I was wondering what pixel-increment the scrolling in the video is showing? (1-pixel, 2-pixel etc?).

Yep, the screen is updated every frame and redrawn, so that way when overlying sprites come along I don't have to worry about preserving the background. It is showing 2 pixel increments there, but the screen resolution is effectively halved to be 160x120, in order to make computations faster and easier. Actually, the animated tiles are only updated every 4th frame, I believe.

tr1p1ea wrote:
I was also wondering what screen mode you are operating in? 8bpp so you can double buffer?

It is in 8bpp mode, and it alternates which buffer it is drawing to and then when updating, it flips the address pointing to the LCD data. This way no screen blitting is actually done, the pointers are just reversed.
It looks very smooth and nice, which is great Smile. So 8x8 tiles then?

I agree that it would be silly to manually copy screen data when you can just adjust a pointer.
It looks to me like his tiles are 16x16 but maybe it's just the screenshot that makes it look that way.

VERY good job on this so far. I love how smooth it is and it's amazing the framerate that you got! Nice work!
Yes, the sprites are 16x16... Which takes up a lot of data. Luckily I plan to make a horizontal sprite flipper routine so I can preserve a lot more space though. The screen is just divided by 2, so an offset of 8 would be a real offset of 16.
Nice work indeed, can't wait to try all that on my CE Smile
Just want to make sure I'm on the same page here, when you say 2 pixel scrolling, you are referring to the fact that you're running in a virtual half res? Or it's 2 virtual pixel scrolling?
tr1p1ea wrote:
Just want to make sure I'm on the same page here, when you say 2 pixel scrolling, you are referring to the fact that you're running in a virtual half res? Or it's 2 virtual pixel scrolling?

It's going by 4 total real pixels technically, but I will probably change that to do just 2 real pixels. Smile

EDIT: Actually, 4 total real pixels is only 1/4 of a block, so I might just leave it the way it is. Meh, we'll see what happens. Smile It will look nice; for sure.

EDIT2: Rather than doing any actual scrolling, which would be ridiculous, the tilemapper just takes a real (well, virtual) x and y offset in HL and DE respectively, and computes where it should draw. Here's the relevant routine (if you can see any optimizations, feel free to point them out! Smile

Code:
DrawMap:
 ld hl,(xoffset)
 ld de,(yoffset)
; X Cord -> HL
; Y Cord -> DE
DispMapAny:
 di
 ld a,l
 and 7
 srl h
 rr l
 srl h
 rr l
 srl h
 rr l   ; x coordinate divided by 8, remainder in A
 neg
 ld (xoffset_smc),a ; store the amount to shift x by... negatively
 ld a,l   ; amount to shift the map index down by
 ex af,af'
  ld a,e
  and 7
  srl d
  rr e
  srl d
  rr e
  srl d
  rr e   ; X coordinate divided by 8, remainder in A
  neg
  ld (yoffset_smc),a ; store the amount to shift y by...
  ld hl,(mapPtr)
  ld a,(hl)
  ld (widthoffset_smc),a
  ld d,a
  mlt de   ; width*yoffset
  add hl,de  ; hl->new starting y location to read from
  ex de,hl
  or a \ sbc hl,hl
 ex af,af'
 ld l,a
 add hl,de
 inc hl
 inc hl
yoffset_smc: =$+1
xoffset_smc: =$+2
 ld bc,0  ; b=xpos
   ; hl->mapdata
drawLoop:
 push hl
  push bc
row:
  ld a,(hl)
  bit animateTilesFlg,(iy+LCDFlgs)
  call nz,animateTiles
  inc hl
  push bc
   push hl
    ld l,258/2   ; l = 258/2 bytes
    ld h,a
    mlt hl  ; hl = half the offset we need :: need hl*2
    add hl,hl
    ld de,tile0_sprite
    add hl,de
    call drawSprite8bppTile
   pop hl
  pop bc
  ld a,b
  add a,8
  ld b,a
  cp 8*numCols
  jr c,row
  pop bc
 pop hl
widthoffset_smc: =$+1
 ld de,0
 add hl,de
 ld a,c
 add a,8
 ld c,a
 cp 8*numRows ; 72
 jr c,drawLoop
 res animateTilesFlg,(iy+LCDFlgs)
 ret
I Have a CE, and would love to help bug test if you pm me test versions.
This is really awesome, Mateo!

When the CSE came out, I tried to get back into learning asm, because the mario I envisioned would allow for custom sprite sheets to use along with level packs and a level editor, Kerm said something like that should have been possible without killing the speed too badly. And allowing older level sets is just awesome. Can't wait to see what you do next with this project. Smile
Dang, I would love a Super Mario World port but I'll settle for any of them I can get. Great work as usual Mateo.
will this work on the CSE?
  
Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.

» Go to Registration page
Page 1 of 19
» All times are GMT - 5 Hours
 
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

 

Advertisement