### Author Topic: Ash: Phoenix- Reboot  (Read 28260 times)

0 Members and 1 Guest are viewing this topic.

#### chickendude

• Posts: 816
• Rating: +90/-1
##### Re: Ash: Phoenix- Reboot
« Reply #45 on: November 12, 2012, 08:30:05 am »
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

#### Hayleia

• Programming Absol
• Coder Of Tomorrow
• LV12 Extreme Poster (Next: 5000)
• Posts: 3367
• Rating: +393/-7
##### Re: Ash: Phoenix- Reboot
« Reply #46 on: November 12, 2012, 11:34:56 am »
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
I own: 83+ ; 84+SE ; 76.fr ; CX CAS ; Prizm ; 84+CSE
Sorry if I answer with something that seems unrelated, English is not my primary language and I might not have understood well. Sorry if I make English mistakes too.

#### squidgetx

• Food.
• Project Author
• LV10 31337 u53r (Next: 2000)
• Posts: 1881
• Rating: +503/-17
• rawr.
##### Re: Ash: Phoenix- Reboot
« Reply #47 on: November 12, 2012, 12:50:21 pm »
How could chickendude not know about chickens?

Joking aside, chickendude is pretty much right about this. 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.

#### Hayleia

• Programming Absol
• Coder Of Tomorrow
• LV12 Extreme Poster (Next: 5000)
• Posts: 3367
• Rating: +393/-7
##### Re: Ash: Phoenix- Reboot
« Reply #48 on: November 12, 2012, 01:00:53 pm »
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
I own: 83+ ; 84+SE ; 76.fr ; CX CAS ; Prizm ; 84+CSE
Sorry if I answer with something that seems unrelated, English is not my primary language and I might not have understood well. Sorry if I make English mistakes too.

#### Streetwalrus

• LV12 Extreme Poster (Next: 5000)
• Posts: 3821
• Rating: +80/-8
##### Re: Ash: Phoenix- Reboot
« Reply #49 on: November 12, 2012, 01:04:30 pm »
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
Encountering enemies is gonna be Pokémon style, I don't see any problem about that.

#### Hayleia

• Programming Absol
• Coder Of Tomorrow
• LV12 Extreme Poster (Next: 5000)
• Posts: 3367
• Rating: +393/-7
##### Re: Ash: Phoenix- Reboot
« Reply #50 on: November 12, 2012, 01:12:51 pm »
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
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
I own: 83+ ; 84+SE ; 76.fr ; CX CAS ; Prizm ; 84+CSE
Sorry if I answer with something that seems unrelated, English is not my primary language and I might not have understood well. Sorry if I make English mistakes too.

#### chickendude

• Posts: 816
• Rating: +90/-1
##### Re: Ash: Phoenix- Reboot
« Reply #51 on: November 12, 2012, 01:20:25 pm »
Hayleia, i think what you're talking about is clipping (having part of a sprite off-screen). Generally, Y clipping is pretty easy: if you want to draw to y position -3 you subtract 3 from the number of rows to draw and add 3 to the starting point of the sprite. It's quick and easy. X clipping is a bit more complicated, however, but still not so bad Axe doesn't have a clipped sprite routine?

EDIT: I've also seen TinyCraft II and it looks really beautiful. And i second squidgetx's request to know how you handle the chickens!
« Last Edit: November 12, 2012, 02:24:13 pm by chickendude »

#### squidgetx

• Food.
• Project Author
• LV10 31337 u53r (Next: 2000)
• Posts: 1881
• Rating: +503/-17
• rawr.
##### Re: Ash: Phoenix- Reboot
« Reply #52 on: November 12, 2012, 01:34:21 pm »
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?
« Last Edit: November 12, 2012, 04:50:03 pm by squidgetx »

#### shmibs

• しらす丼
• LV11 Super Veteran (Next: 3000)
• Posts: 2132
• Rating: +281/-3
• try to be ok, ok?
##### Re: Ash: Phoenix- Reboot
« Reply #53 on: November 12, 2012, 03:58:07 pm »
squidget, you could potentially do to handle NPCs would be to have a set period when entities can move and use that both for the player and any other moving entities. then you could handle them all the same way, calculating movement directions(NPC being directed with rand and player with key strokes), then collision interactions (the same way for both), then entering the movement phase (which is made up of multiple frames during which the map may or may not be scrolling, depending on whether the player moved or not) and moving and drawing all the NPCs the same way you did the main character (/me is assuming that you are already scrolling on a back buffer and copying it to the front to draw your player; if you're doing it a different way, then i'd be very interested to find out how)
« Last Edit: November 12, 2012, 03:58:32 pm by shmibs »

#### squidgetx

• Food.
• Project Author
• LV10 31337 u53r (Next: 2000)
• Posts: 1881
• Rating: +503/-17
• rawr.
##### Re: Ash: Phoenix- Reboot
« Reply #54 on: November 12, 2012, 07:49:14 pm »
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.

Code: [Select]
-Draw the map using the bitmap routine because I don't have a clipped 12x12 tile routineWhile 1   ;main loop if key=left  left() end if key=right  right() end etc...display()endlbl rightreturn if check tilemapreturn if check npcscopy 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.asmfor 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 flagrr 2 bytes of the sprite bankrr 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 asmdisplay()endplayerX++if playerX is off the edge of the mapmapX++loadmapenddecide if an npc was scrolled in, if so draw it using nibble-aligned mask routinecheck if you're standing on a door, if so, warp to where it leadsreturnlbl leftlooks like right, only uses rl instead of rr and doesn't need to shift the tiles by 1 nibblelbl up/downsame as right, only asm routine is a little different for shifting verticallylbl displayis the map location box on? if so...decrease map location box time counterback up area of screen where map box is drawndraw map boxback up area of screen where character is drawndraw character using mask routinedispgraph^rwas there a map box? restore that area of the screenrestore the area of the screen where the character is drawnlbl loadmaptakes 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.
« Last Edit: November 13, 2012, 03:13:50 am by Art_of_camelot »

#### Hayleia

• Programming Absol
• Coder Of Tomorrow
• LV12 Extreme Poster (Next: 5000)
• Posts: 3367
• Rating: +393/-7
##### Re: Ash: Phoenix- Reboot
« Reply #55 on: November 13, 2012, 02:01:20 am »
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.
I don't know if it is the fastest way but I am quite sure that it is faster than saving the screen or redrawing every frame
I own: 83+ ; 84+SE ; 76.fr ; CX CAS ; Prizm ; 84+CSE
Sorry if I answer with something that seems unrelated, English is not my primary language and I might not have understood well. Sorry if I make English mistakes too.

#### squidgetx

• Food.
• Project Author
• LV10 31337 u53r (Next: 2000)
• Posts: 1881
• Rating: +503/-17
• rawr.
##### Re: Ash: Phoenix- Reboot
« Reply #56 on: November 13, 2012, 10:11:51 am »
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)

#### squidgetx

• Food.
• Project Author
• LV10 31337 u53r (Next: 2000)
• Posts: 1881
• Rating: +503/-17
• rawr.
##### Re: Ash: Phoenix- Reboot
« Reply #57 on: November 14, 2012, 08:16:02 pm »
Update

As usual, source and build in the first post.

-Optimized
-NPC system basically works
-Custom font
-Automatic wordwrapping
-Some other bug fixes

Next on the list:
-battttleleelelel engineee
« Last Edit: November 14, 2012, 08:20:22 pm by squidgetx »

#### Eeems

• Mr. Dictator
• LV13 Extreme Addict (Next: 9001)
• Posts: 6182
• Rating: +318/-36
• little oof
##### Re: Ash: Phoenix- Reboot
« Reply #58 on: November 16, 2012, 02:20:42 pm »
looking good!
/e

#### DJ Omnimaga

• Former TI programmer
• CoT Emeritus
• LV15 Omnimagician (Next: --)
• Posts: 55832
• Rating: +3151/-232
• CodeWalrus founder & retired Omnimaga founder
##### Re: Ash: Phoenix- Reboot
« Reply #59 on: November 16, 2012, 05:49:24 pm »
Very nice. By the way for NPCs, if they can move around, try to make sure that we can talk to them even if they're starting to move away from us. In RPG Maker 2003, that doesn't happen and talking to NPCs that moves at a fast interval is incredibly hard.

Also, make sure that if you're trying to move in a narrow passage and a NPC gets in the way, that he gets out of the way. This was a serious problem in Final Fantasy: Mystic Quest on the SNES, especially the 2nd village, where reaching certain parts was close to impossible.
In case you are wondering where I went, I left Omni back in 2015 to form CodeWalrus due to various reasons explained back then, but I stopped calc dev in 2016 and am now mostly active on the CW Discord server at https://discord.gg/cuZcfcF