Does it constantly archive and unarchive areas that it loads in/out?I guess it keeps all in Archive and uses files to not waste time with archiving ;)
Major mapping update :DWow, that's an awfully large world you will have to play with. Very impressive! :D The mapper is looking quite smooth so far. Nice work!
(http://img.removedfromgame.com/imgs/pscreen2.gif)
-Finished custom asm mask routine (although I need to change it a little to draw to any tile once I implement NPCs) Yeah, the routine is kinda poorly written; I'll eventually get around to optimizing it. Don't look! But the important thing is that it works for now lol
-Sprited character and animations
-Optimized/modularized movement code to allow tap-to-face-direction and improved speed with one change.
-Draws black automatically if shifting in non-existent data
-Last, but most definitely not least, implemented seamless map transitions. Remember in the demo and in Embers, in order to change areas you HAD to go through a door or something? No longer; now you don't notice anything when you move from one area to another (well, if you look really closely the grayscale flickers a tiny bit). Effectively, the world the player inhabits is 9216x9216px or 768x768 tiles...That's 589,824 tiles, or over 13,000 screens of world all seamlessly put together. The screenshot shows the character walking around on the edges of 3 areas. It only takes 2kb of RAM to run this mapping system :D
As usual, the build and source can be found in the first post (http://ourl.ca/12140/228929)
To-do:
-Collision detection + map switching via portals/doors
-Fix up mask routine
-NPC render engine (then I'll be done with all the overworld stuff...)
Major mapping update :DOooohhh my ! Things are coming along faster than I expected.
(http://img.removedfromgame.com/imgs/pscreen2.gif)
-Finished custom asm mask routine (although I need to change it a little to draw to any tile once I implement NPCs) Yeah, the routine is kinda poorly written; I'll eventually get around to optimizing it. Don't look! But the important thing is that it works for now lol
-Sprited character and animations
-Optimized/modularized movement code to allow tap-to-face-direction and improved speed with one change.
-Draws black automatically if shifting in non-existent data
-Last, but most definitely not least, implemented seamless map transitions. Remember in the demo and in Embers, in order to change areas you HAD to go through a door or something? No longer; now you don't notice anything when you move from one area to another (well, if you look really closely the grayscale flickers a tiny bit). Effectively, the world the player inhabits is 9216x9216px or 768x768 tiles...That's 589,824 tiles, or over 13,000 screens of world all seamlessly put together. The screenshot shows the character walking around on the edges of 3 areas. It only takes 2kb of RAM to run this mapping system :D
As usual, the build and source can be found in the first post (http://ourl.ca/12140/228929)
To-do:
-Collision detection + map switching via portals/doors
-Fix up mask routine
-NPC render engine (then I'll be done with all the overworld stuff...)
Fill(L6,768,$FF)
DispGraph
Pause 400
It's the same fade I use in a lot of games, haha. For some reason (maybe it's the screen driver or something) it just looks really clean and awesome. The code is literallyWait, so you just make the screen black and pause it for a while? oOCode: [Select]Fill(L6,768,$FF)
DispGraph
Pause 400
are NPC's going to be able to move at all? are you going to have some sort of cutscene scripting? how is encountering enemies going to work?No, yes, same as the demo.
I've kept watching the screenshot and I can't figure out how you did the clean fade transition between maps - or is that just a Wabbit artifact?
Also with a lot of NPCs that would most likely slow the game down quite a bit. It's also a lot of work to implement all the NPC patterns and stuff.If you only handle NPCs that are on screen it wouldn't be so bad, especially since squidgetx's maps are divided into submaps. The real issue here is that the screen isn't updated every frame, so not only would every NPC require a mask, you'd also have to save what was drawn below before drawing the NPC on top and then refill it before redrawing the NPC in its new position. And if you move while an NPC is moving, you'd either have to freeze the NPC and wait until you stop moving to continue its movement or use a different method to shift the screen. With only one or two NPCs on screen it probably wouldn't noticeably slow the game down, any more though and you'd likely start feeling the effects. It's really just a pain to code and would probably be easier just to rewrite the whole thing to use a slower but more flexible mapper that redraws the screen every frame :P
I see you haven't seen TinyCraft's chickens. And if even I can get those to work, there is no doubt that squidgetx will manage to get NPCs without any speed loss ;)Also with a lot of NPCs that would most likely slow the game down quite a bit. It's also a lot of work to implement all the NPC patterns and stuff.If you only handle NPCs that are on screen it wouldn't be so bad, especially since squidgetx's maps are divided into submaps. The real issue here is that the screen isn't updated every frame, so not only would every NPC require a mask, you'd also have to save what was drawn below before drawing the NPC on top and then refill it before redrawing the NPC in its new position. And if you move while an NPC is moving, you'd either have to freeze the NPC and wait until you stop moving to continue its movement or use a different method to shift the screen. With only one or two NPCs on screen it probably wouldn't noticeably slow the game down, any more though and you'd likely start feeling the effects. It's really just a pain to code and would probably be easier just to rewrite the whole thing to use a slower but more flexible mapper that redraws the screen every frame :P
How could chickendude not know about chickens????Lol, didn't think about that one :P
I'm not sure how TinyCraft's mapper works, but the fact that it uses 8x8 tiles gives it a huge advantage over anything that I can come up with right now. 8x8 tiles are fast and flexible, making it easy to build a grayscale redraw-every-frame mapper that could easily support moving chickens. On the other hand, if you don't update every frame, it's still not too difficult to save the screen, draw the chickens, and recall the image (which is what I could theoretically do...only it would cause a very very noticeable speed drop, plus I have to change/write an unaligned 12x16 mask routine, which I don't want to do just for the sake of having moving npcs.I don't redraw the screen at every frame (that would be too slow) and can't save the entire screen either, that would be too slow and wouldn't work with the greyscale interrupt.
Encountering enemies is gonna be Pokémon style, I don't see any problem about that.How could chickendude not know about chickens????Lol, didn't think about that one :PI'm not sure how TinyCraft's mapper works, but the fact that it uses 8x8 tiles gives it a huge advantage over anything that I can come up with right now. 8x8 tiles are fast and flexible, making it easy to build a grayscale redraw-every-frame mapper that could easily support moving chickens. On the other hand, if you don't update every frame, it's still not too difficult to save the screen, draw the chickens, and recall the image (which is what I could theoretically do...only it would cause a very very noticeable speed drop, plus I have to change/write an unaligned 12x16 mask routine, which I don't want to do just for the sake of having moving npcs.I don't redraw the screen at every frame (that would be too slow) and can't save the entire screen either, that would be too slow and wouldn't work with the greyscale interrupt.
But now that I think again about how they work, they have a drawback that will be very annoying for 16x16 sprites: they can't be drawn if they are too close from the border of the screen. Ideally, a border of 2 pixels would be needed (but since I code bad, I put a bigger limit :P).
So if there will be enemies in your game, not seeing them coming would be a huge issue :-\
Erm, I don't know at all how to say that in English -.-°Encountering enemies is gonna be Pokémon style, I don't see any problem about that.How could chickendude not know about chickens????Lol, didn't think about that one :PI'm not sure how TinyCraft's mapper works, but the fact that it uses 8x8 tiles gives it a huge advantage over anything that I can come up with right now. 8x8 tiles are fast and flexible, making it easy to build a grayscale redraw-every-frame mapper that could easily support moving chickens. On the other hand, if you don't update every frame, it's still not too difficult to save the screen, draw the chickens, and recall the image (which is what I could theoretically do...only it would cause a very very noticeable speed drop, plus I have to change/write an unaligned 12x16 mask routine, which I don't want to do just for the sake of having moving npcs.I don't redraw the screen at every frame (that would be too slow) and can't save the entire screen either, that would be too slow and wouldn't work with the greyscale interrupt.
But now that I think again about how they work, they have a drawback that will be very annoying for 16x16 sprites: they can't be drawn if they are too close from the border of the screen. Ideally, a border of 2 pixels would be needed (but since I code bad, I put a bigger limit :P).
So if there will be enemies in your game, not seeing them coming would be a huge issue :-\
-Draw the map using the bitmap routine because I don't have a clipped 12x12 tile routine
While 1 ;main loop
if key=left
left()
end
if key=right
right()
end
etc...
display()
end
lbl right
return if check tilemap
return if check npcs
copy tiles to be shifted in (column 4 tiles to right of player) into spritebank (L1)
shift those tiles over 1 nibble (remember tiles are 12x12 but stored as 12 rows of 2 bytes with a 0 in the 4th nibble)
for 12 (run for 1 tile)
...this part in assembly, see screenshift.asm
for all 64 rows on the screen
;for those unfamiliar with asm, the rr (hl) command shifts hl right 1 bit (1 pixel), the bit shifted in comes from the carry flag,
;and the bit shifted out goes into the carry flag
rr 2 bytes of the sprite bank
rr the whole screen row
;this shifts the whole screen like axe horizontal, only instead of shifting in blank pixels, it shifts in the rightmost column of pixels from the spritebank
...end asm
display()
end
playerX++
if playerX is off the edge of the map
mapX++
loadmap
end
decide if an npc was scrolled in, if so draw it using nibble-aligned mask routine
check if you're standing on a door, if so, warp to where it leads
return
lbl left
looks like right, only uses rl instead of rr and doesn't need to shift the tiles by 1 nibble
lbl up/down
same as right, only asm routine is a little different for shifting vertically
lbl display
is the map location box on? if so...
decrease map location box time counter
back up area of screen where map box is drawn
draw map box
back up area of screen where character is drawn
draw character using mask routine
dispgraph^r
was there a map box?
restore that area of the screen
restore the area of the screen where the character is drawn
lbl loadmap
takes mapX, mapY as arguments (there is a large tilemap, a tilemap of tilemaps or metamap/overworld)
decompress 9 16x16 tilemap chunks from archive into a 48x48 RAM tilemap in a 3x3 square where the middle one is the map with coords (mapX,mapY) (if there is no 16x16 chunk to load or if its value is zero, fill will black tiles)
Hayleia, I'm curious as to how you do your chickens then, if you don't save the screen nor redraw every frame.When the chicken is on the screen, I use pt-get to see what is beneath it, then I draw it and I use what I stored by the pt-get to erase it. And now you see why I can't draw the chicken if it is too close from the border of the screen because if the chicken just entered on the screen, the pt-get recorded some crap outside of the screen so erasing the chicken before drawing it will draw garbage.
Lbl Text
Until offset = offset + length of conversation
{Conversation pointer + offset} -> Char
Offset++
If char>31 ;if character is alphanumeric or common symbol
offset->temp
curX->temp2
while {conversation + temp} - 32 ;while not a space
temp++
temp2+4->temp2 ;custom font all letters are 4px wide
end
if temp2 > 92 ;if word needs to be wrapped
4->curX
if next line available
set curY to next row
else
reset curY
pause and wait for keypress
erase previous text
end
display character at curX, curY (with custom font routine)
curX+4->curX
dispgraph
end
end
Thanks guys!Yepp, sounds good. Not being able to escape for no good reason has always been irritating.
I'm thinking about having the run-away mechanic work with 100% success rate. You just risk getting hit an extra time by your enemy if the random factor "fails," but you'll always be able to escape battle. Thoughts on this?
(http://img.removedfromgame.com/imgs/pscreen7.gif)
(http://img.removedfromgame.com/imgs/pscreen9.gif)
not yet, progress is slowing atm because I just moved to another country on the other half of the world lol
Once things settle down I'll have a bit more time to work it out.
my spannis is crappy.
Yeah I meant spanish, stupid phone... -_-'my spannis is crappy.
I hope you meant Spanish... O.O
And yeah French would be nice. Should not be too hard if the text is easy to extract. :D
yeah! this looks awesome!
he should definitely finish it
Would have been a good RPG maker for calcs.^this :D
Finally got around to putting up the source on git. School and stuff has kept me insanely busy unfortunately. Would be awesome to come back to this project at some point, but not much time these days :(
Hopefully I can get around to improving the documentation but everything anyone might need to continue the project should be able to be found here.
https://github.com/squidgetx/Phoenix