Author Topic: OmniRPG - Coding (Read 66707 times)

Xeda112358 · « **Reply #105 on:** December 10, 2012, 03:43:50 pm »

Actually, that would still be easy to do with my map, but I plan to try another method (one I've described before) once I get time. I have exams tomorrow and the next day

stevon8ter · « **Reply #106 on:** December 10, 2012, 03:49:06 pm »

I've already got exams from thursday.. Till next week tuesday, but haven't felt like learning... Omnimaga distracts me xD

willrandship · « **Reply #107 on:** December 10, 2012, 06:39:04 pm »

So, if we use Xeda's, do we have pokemon-style walking, locking to each tile but smooth scrolling, or would we have smooth movement except when loading the sides?

Sorunome · « **Reply #108 on:** December 10, 2012, 06:47:03 pm »

I would go with totally smooth, not-locked to tiles.

Xeda112358 · « **Reply #109 on:** December 10, 2012, 06:47:48 pm »

You get Pokémon style walking with the engine I made. By the way, here is the updated source (attached to the post). If you want to scroll in any direction, you just need to use sub() and it will update everything. I still need to add code to recognise the edge of the map, though. The code, currently:

Code: [Select]

:.MAPTEST
:0→Str2→X
:ClrDraw
:38510→Str3
:13→W
:16→H
:{-}8→Y
:For(8)
:sub(SMU
:End
:DiagnosticOff
:Repeat getKey(15)
:If getKey(3)
:sub(SMR
:End
:If getKey(2)
:sub(SML
:End
:If getKey(1)
:sub(SMD
:End
:If getKey(4)
:sub(SMU
:End
:End
:Return
:Lbl SMD
:For(I,0,7
:Vertical +
:X-1*H+Y+Str2→A
:For(B,0,11
:{A+H→A}
:{*2*2*2+Str1+I}→{{L6}+B}
:End
:DispGraph
:End
:Y--
:Return
:Lbl SMU
:Y++
:For(I,0,7
:Vertical -
:X-1*H+Y+8+Str2→A
:For(B,756,767
:{A+H→A}
:{*2*2*2+Str1+I}→{{L6}+B}
:End
:DispGraph
:End
:Return
:Lbl SMR
:sub(CLD
:X--
:For(8)
:Asm(116E962140930E40EBCB1EEB060CCB1E2310FB1C0D20F1
:DispGraph
:End
:Return
:Lbl SML
:sub(CLD
:X++
:For(8)
:Asm(11EE962140960E401DEBCB16EB060C2BCB1610FB0D20F1
:DispGraph
:End
:Return
:Lbl CLD
:X-1*H+Y+Str2→A
:Str3→B
:sub(CLD0
:X+12*H+Y+Str2→A
:sub(CLD0
:0→A
:Return
:Lbl CLD0
:For(8)
:B
:Asm(E5
:{A++}*2*2*2+Str1
:Asm(D1010800EDB0EB
:→B
:End
:Return
:[00000000000000003C4281818181423C3C7EFFFFFFFF7E3C]→Str1

willrandship · « **Reply #110 on:** December 10, 2012, 06:50:20 pm »

Actually, if you do like pokemon even more, you don't need edge-of-map detection. Just make sure there are enough tiles beyond walkable areas that the user never sees past them, and trigger tiles load in the other maps.

Scipi · « **Reply #111 on:** December 10, 2012, 07:48:14 pm »

Quote from: willrandship on December 10, 2012, 06:50:20 pm

Actually, if you do like pokemon even more, you don't need edge-of-map detection. Just make sure there are enough tiles beyond walkable areas that the user never sees past them, and trigger tiles load in the other maps.

That's exactly what pokemon does. In fact, if you hack the game to see past the areas you aren't supposed to see, the game will actually crash in the original R/B/Y games.

I think pokemon like movement would go well. Else, if it's not too demanding a FFVI like approach could also work well.

willrandship · « **Reply #112 on:** December 11, 2012, 01:40:52 am »

Makes sense, although I'm surprised it crashes rather than behave like the missingno glitch. Although, I guess event tiles (like load map triggers) could be written to have inlined code, and hence a corrupted one could be VERY messy.

How exactly is FF6 different aside from having entirely separate areas? Or, is that what you were referring to?

Scipi · « **Reply #113 on:** December 11, 2012, 02:19:01 am »

Quote

Makes sense, although I'm surprised it crashes rather than behave like the missingno glitch. Although, I guess event tiles (like load map triggers) could be written to have inlined code, and hence a corrupted one could be VERY messy.

The missingno glitch just causes graphical artifacts due to a corrupted stat page. Viewing any normal pokemon stat page will actually fix the problem. With the tiles themselves, I would imagine it would be to an uncaught index out of bounds exception. It would essentially end up reading nonsense data for sprites, animations, events, transition points, NPC's, etc for that area beyond the map. That could cause quite a few nasty effects, and ultimately, a crash

Quote

How exactly is FF6 different aside from having entirely separate areas? Or, is that what you were referring to?

In FF VI your movement was non-tile based. Your movement and position was pixel based and was referred to a tiled based map. Much like LoZ is.

Xeda112358 · « **Reply #114 on:** December 11, 2012, 06:20:08 am »

I think Edge-Of-Map detection won't actually be difficult and it would save on map data size. All I have to do is test if X>32767 (meaning it is negative) for the left edge, X+11>H for the right edge, and similar for the upper and lower edges. Either way, I have more shtuff >.>

I woke up at 1:00 or 2:00 (around there) and I couldn't sleep, so I instead came up with an altered idea for animated tiles. Basically, I will keep an LUT that keeps track of the evolution of the tiles, that way, when I load in a new tile, I can use the LUT to see where it has evolved to. Now we can have groups of tiles that will be in the same frame when they are newly loaded in

However, I have a final exam soon, so I will not be focused on this, yet.

TIfanx1999 · « **Reply #115 on:** December 11, 2012, 08:23:57 am »

Pokemon style movement is pretty traditional for RPGs. It should work fine.

Also, have we discussed having a seamless overworld (pokemon) or a map based one (Final Fantasy IV/VI)?

Also Xeda,How many frames are you going to allow per animated tile? I don't think we need but 2 or 3.

Scipi · « **Reply #116 on:** December 11, 2012, 08:40:50 am »

Quote

Also, have we discussed having a seamless overworld (pokemon) or a map based one (Final Fantasy IV/VI)?

Well, so far as the story is working out we will want to convey the idea that this world is quite massive. So a map based overworld would work better for giving that sense of scale as opposed to a seamless one where the "view" of the world is close up to the character and ground and doesn't easily convey landmasses.

TIfanx1999 · « **Reply #117 on:** December 11, 2012, 08:44:09 am »

Mmkay, sounds good to me.

willrandship · « **Reply #118 on:** December 11, 2012, 02:13:41 pm »

I like the idea of a big overworld map, but that doesn't restrict us from having internal town maps and the like.

P.S. Best SNES game ever if you love overworld maps: Uncharted Waters. (New Horizons, the sequel, is better)

Xeda112358 · « **Reply #119 on:** December 11, 2012, 03:42:34 pm »

Quote from: Art_of_camelot on December 11, 2012, 08:23:57 am

Pokemon style movement is pretty traditional for RPGs. It should work fine. Also, have we discussed having a seamless overworld (pokemon) or a map based one (Final Fantasy IV/VI)?

Also Xeda,How many frames are you going to allow per animated tile? I don't think we need but 2 or 3.

The way I have it planned, the only limit will be that you can have as many as 256 tiles. So if you made 64 tiles with three frames, then 16 other tiles with one frame, then 8 tiles with six frames, you would be fine. In fact, the method I have won't even require that you have tile data for 256 tiles. If several tiles use the same data, they can all point to the data

This will be more useful for tiles that we want to look like one frame longer than another (basically, you have it evolve into a tile that looks the same).

Author Topic: OmniRPG - Coding (Read 66707 times)

Xeda112358

Re: OmniRPG - Coding

stevon8ter

Re: OmniRPG - Coding

willrandship

Re: OmniRPG - Coding

Sorunome

Re: OmniRPG - Coding

Xeda112358

Re: OmniRPG - Coding

willrandship

Re: OmniRPG - Coding

Scipi

Re: OmniRPG - Coding

willrandship

Re: OmniRPG - Coding

Scipi

Re: OmniRPG - Coding

Xeda112358

Re: OmniRPG - Coding

TIfanx1999

Re: OmniRPG - Coding

Scipi

Re: OmniRPG - Coding

TIfanx1999

Re: OmniRPG - Coding

willrandship

Re: OmniRPG - Coding

Xeda112358

Re: OmniRPG - Coding