- Oiram [TI84+CE]
- 17 Sep 2015 05:03:02 pm Permalink
- Last edited by MateoConLechuga on 05 Jan 2017 06:26:59 pm; edited 8 times in total
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.
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.
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
.
"My world is Black & White. But if I blink fast enough, I see it in Grayscale."
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 . So 8x8 tiles then?
I agree that it would be silly to manually copy screen data when you can just adjust a pointer.
. So 8x8 tiles then?
I agree that it would be silly to manually copy screen data when you can just adjust a pointer.
"My world is Black & White. But if I blink fast enough, I see it in Grayscale."
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!
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.
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?
"My world is Black & White. But if I blink fast enough, I see it in Grayscale."
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.
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.
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!
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
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.
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.
Register to Join the Conversation
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
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
Latest Headlines
There are 645 users online: 2 members and 643 guests.
Members: Minxrod, Scocus.
Members: Minxrod, Scocus.
RSS & Social Media
![[t]](/forum/templates/Cemetech6/images/twitter.png)
![[f]](/forum/templates/Cemetech6/images/fb.png)
![[RSS]](/forum/templates/Cemetech6/images/rss.png)
SAX
You must log in to view SAX chat widget.
Advertisement
© Copyright 2000-2019 Cemetech & Christopher Mitchell :: Page Execution Time: 0.190231 seconds.