Quote from: DJ_O on November 10, 2012, 03:37:59 pm

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

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

How could chickendude not know about chickens?

Lol, didn't think about that one

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.
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 ).
So if there will be enemies in your game, not seeing them coming would be a huge issue

Quote from: Hayleia on November 12, 2012, 01:00:53 pm

Quote from: squidgetx on November 12, 2012, 12:50:21 pm

How could chickendude not know about chickens?

Lol, didn't think about that one

Quote from: squidgetx on November 12, 2012, 12:50:21 pm

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.
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 ).
So if there will be enemies in your game, not seeing them coming would be a huge issue

Encountering enemies is gonna be Pokémon style, I don't see any problem about that.

Erm, I don't know at all how to say that in English -.-°
When an enemy comes, you should be able to see him as soon as he has a body part on the screen (then you see that said body part).
But in TinyCraft, even when the enemy could entirely be drawn on the screen, if he is too close from the border of the screen, he is not drawn. There is the problem.

But by Pokémon style, do you mean "non-moving enemies" ? Because if they don't move, there is no problem. But I think that enemies in A:P will move, so my method will not be appliable

Axe should have a clipped sprite routine, and Hayleia, enemies are going to be encountered pokemon style (different from Embers). When I say "NPC" I mean like the guys that stand around and can talk to you.

Hayleia, I'm curious as to how you do your chickens then, if you don't save the screen nor redraw every frame.

Chickendude, Axe's sprite routines have clipping.
I already wrote that...why did I write it again?

You can all check out the source, it's in the first post. But if you don't wanna dig through my code, I'll give some condensed pseudocode here.

-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)


The screen is basically never cleared-- when you move, you move one tile at a time, animated by a For(12) loop. Within that loop, the screen is shifted by 1 pixel, and what's shifted in is only the single pixel row/column that needs to be shifted in. The assembly routine is remarkably easy/elegant/efficient this way--by shifting the spritebank data, it's already setting itself up for the next iteration. NPCs, since they're not part of the tilemap and thus not detected by the regular shift/drawing routine, are drawn after they've come into view. Anything that isn't going to scroll with the map movement (like the player himself) needs to have the area where they're drawn backed up before they're drawn. This engine is remarkably fast (easy 45fps) but a pain to work with as I add more and more elements (just the map name box and the animated player are enough for me, haha)

Edit: let me know if you guys have any other questions about the engine or anything, i don't know how good this explanation is haha

*Edit* AOC: fixed code box as it wasn't displaying in FF.

Oh, ok. Yeah, pt-get can be useful like that, but like I said, that method only works with 8x8 sprites =/ (and has the added disadvantage you described with clipping)

looking good!