Messages

How large is the file?  I wouldn't mind hosting it here.

You are correct that many animations have different fps for each frame.  The animations are based on variable delays between frames rather than a preset frame rate.  Unfortunately I don't believe I ever programmed a way to view these values into the editor.

... (And if it helps any, we're all likely destined to die some day. - Depending on whether there are new breakthroughs in science... er... nevermind.) ...

You stop that train of thought right now.  You're talking 1.5% chance scenario for an average 50 year old there.  I'm a 27 year old physically fit member of the military whose immune system has international experience.

I don't comment here as often as I should, but as usual I'm impressed by the quality of your remixes.  I'm going to buy the album so I can add it to my collection of video game music.

@Neshi, Excellent work on the Nightfall vocals indeed, it sounds professionally done.


I don't know much about music, but I did spend several years at an arts school so excuse me while I pretend to know what I'm talking about.

I think the artwork compliments to music really well for the most part with a small exception.  I really like that scene of Isaac, Garet and Ivan looking at the destruction of the forest for "Hymn for the Broken Forest", but the artwork for "Troubles of the Townsfolk" seems to do little to compliment the sad tone of the music.  In fact, the smile on the lumberjack's face makes it look the destruction is a good thing.  I'm a little torn on the "Curse of Kolima" artwork, it's spot on for the music starting around 1:30~1:40 but it feels downright morbid compared to the tone of anything in the games.  I don't know whether to praise you for making me feel certain feelings, or if I prefer the bitter "after the disaster" sadness in game to the shock of witnessing it first-hand.  I guess it depends more on what you're trying to achieve.  Either way, I like what I'm seeing so far.

Sorry, I didn't mean to worry everyone over my potential illness, I was having a bad day.  Nothing serious has happened yet, it's only worrying symptoms so far.  I don't want to go into details, but there's really only about a 5% chance there's something seriously wrong with me.  I'm just frustrated because they won't be able to do the tests to find out for sure until the end of July.

Perhaps.  Problem is it's an ambitious project I'm trying to make as a hobby alone while working a rather demanding full time (Sometimes more than) job.

@Seto, stressed out, and depressed.  Oh, and after that started I found out I might have a life threatening illness, or maybe nothing, I dunno.  None of the doctors I've seen so far could say what's wrong me.


I don't know why this image never made it into this topic, it's the only other one I've released so far.

Rom Hack Downloads

I know the downloads add-on to the forums has an awful interface, but it's still better than searching the forums for files.

I don't think it really matters if the compiled code is the same as long as the gameplay/feel of the end product is the same.  Though I do have a pretty strict definition for "feeling" the same, the vast majority of fan games will never get something as basic in the engine as the collisions while walking around right.

The Open Source Golden Sun project is closer to what the original plan for the editor was anyway, I'd be pretty happy to see it reach a point that makes the editor obsolete.

...Your first name wouldn't happen to be Michael, would it?

It's John

I liked Farscape better than Jurrassic Park anyway.

Welcome to the forums, Crichton, I hope you enjoy your time here.

Does anyone have some good game saves where all characters are in the parties etc...? If anyone could help me out and provide some good ones for GS and GS:TLA that'd be perfect.

For all saves in the original Golden Sun I'll refer you here, and the TLA equivalent is here.  (Megaupload link is broken, but goldensunhacking.net mirror still works)


EDIT:
Now that I really think about it, I believe the background is moving the exact same speed in both of our examples relative to the rotation speed since both of the GIF animations are only 1 rotation, and the background loops perfectly in both of them.  Maybe my background is x2 speed?  Either way the ratio has to be such that 1 rotation = a whole cycle of the background too.

• As you can see in my implementation the background is scrolling slower than yours. Can you tell me how you are determining the speed of your background scrolling? Personally I just take the camera angle 0-360 degrees and translate that to an x-coordinate on the image background.

As I've said, I don't have the original source used to create that demonstration any more.  As I recall I just went with my best guess at what looked good at the time scaled by the camera's relative distance, so it was basically just an arbitrary decision.

• Your background scrolling somehow seems smoother or as if there is motion blurring. Is that the gif or did you actually put that in?

I believe I did have texture interpolation enabled while drawing the background, so there would have been some "blurring" due to trying to calculate colors between pixels at non-round number coordinates.  Yours is probably more accurate to how Golden Sun really is since the GBA hardware is not capable of interpolation.

• I've noticed in the actual game that Sheba seems a lot smaller than Felix. Is there some special consideration for their size that the game does? The current depth calculation doesn't seem to take that into account. If you look at my implementation Sheba is the same height as Jenna. If you look in this image that is not the case.

I'll refer you back to where I mentioned a "defaultScale" value in my explanation.

Now, as for field of view and how it affects the scaling of the sprite on screen, it's all a matter of ratios.  Think of the field of view as a cone that extends out from the camera, the size of this cone increases at a fixed ratio (scaleRatio) as the distance increases.  The size a character appears to be on screen is proportional to the amount of that cone they fill, so their sprite's scale will be inverse to scaleRatio multiplied by their distance from the camera.

scale = defaultScale / (scaleRatio * distance)

When initialized defaultScale (normally 1) should be multiplied by (scaleRatio * cameraDist) replacing cameraDist with your camera's default/neutral distance if you want to make the camera distance variable.

The Golden Sun engine has an equivalent for "defaultScale" stored with the sprite data.  You can view this value in the GS:TLA Editor.

For reference:

Isaac: 0.75
Garet: 0.85
Ivan: 0.75
Mia: 0.75
Felix: 0.75
Jenna: 0.75
Sheba: 0.75
Piers: 0.75

(It's my mistake that 0.75 seems to be Golden Sun's default value for defaultScale)

The data doesn't support Sheba being intentionally drawn smaller, Garet is the only odd one out.  I suspect it has something to do with the exact positioning of the characters, and rounding due to the GBA not supporting interpolation.  Still though, looking closely at your comparison image with the Wild Wolf the size of the wolf doesn't look right for this method.  It could be that Golden Sun's battle engine is more faked than I had suspected.

• What camera rotation speed do you use? I go 1 degree every frame @ 60fps.

I don't recall, but it wasn't based on anything from the real Golden Sun's engine.  I don't think I've stressed this yet, but I haven't actually looked into the code for how the real Golden Sun's battle engine works as far as faking the 3D effect.  Everything I've said is based on my own knowledge/research, and how I would go about creating the same effect.

This topic has some in depth info on the GBA's music format in a spoiler at the bottom of the first post, and in the second post.

As far as programming something for music in RPG Maker, I can't really help since I don't know enough about it's scripting language.  I have my doubts that it provides low enough level audio stream access to do it properly though.

I responded to your PM, but I'll post it here too cause it's good information other people might want as well.

Hey Atrius,

When you have a chance, can you expand on this? Specifically how the sprites are positioned and how you are translating the recalculated coordinates back to screen coordinates?

Sorry I haven't been on in a while.

I'll go over it all, but I'm working it out in my head from what I can remember of the process so forgive me if I make any mistakes.

The character's X and Y coordinates are completely different from the X and Y coordinates where their sprites are drawn on screen.  I'll call the sprite coordinates spriteX and spriteY.  As the camera rotates I don't change the values of X and Y, spriteX and spriteY get recalculated based on the camera's new position.  X and Y are located on a plane that extends into the screen, basically they're a location on the ground as it is visible on screen where 0, 0 is at the center.

Perhaps a better way to explain the X, and Y coordinates are that they're as though you were looking down on the battle from directly above it.   

To calculate spriteX and spriteY you need to perform a rotation on X and Y so:
spriteX = X  * cos(-cameraAngle) - Y * sin(-cameraAngle)
spriteY = Y * cos(-cameraAngle) + X * sin(-cameraAngle)

That's not all though, now spriteX and spriteY need to be translated to screen coordinates.  This also includese scaling the sprite based on spriteY which currently represents how far forward or back they are on the ground, rather than how far up or down they are on the screen.

spriteX and spriteY still represent a top down view at this point, but it's been rotated so that the spriteY axis is the direction the camera is pointing, and the spriteX axis is perpendicular to it.  At this point you could use the spriteY values to sort your sprite drawing order.


Note that 0, 0 is still located at the center of the grid, this will be important later.


Now, for the next step it's important to know how perspective works.  There are two variables to consider when calculating how large the sprites should appear on screen: their distance from the camera, and the camera's field of view.  Since the camera, rather than just being a single point in space, can be considered a flat viewing plane parallel to the spriteX axis we can ignore spriteX when calculating distance to avoid weird fisheye distortion effects leaving us with just spriteY for the calculation.  The camera is NOT at the center of our coordinate system though so you'll have to use an offset to represent the camera's location on the spriteY axis. This offset is equal to the camera's distance from the center of the battlefield, so I'll call it "cameraDist"

distance = cameraDist - spriteY

Note that a negative distance value would mean the character is behind the camera, and should not be drawn at all.  On second thought, also include 0 in that.  So less than or equal to zero means they're not drawn, we wouldn't want to go dividing by zero later on.


Now, as for field of view and how it affects the scaling of the sprite on screen, it's all a matter of ratios.  Think of the field of view as a cone that extends out from the camera, the size of this cone increases at a fixed ratio (scaleRatio) as the distance increases.  The size a character appears to be on screen is proportional to the amount of that cone they fill, so their sprite's scale will be inverse to scaleRatio multiplied by their distance from the camera.

scale = defaultScale / (scaleRatio * distance)

When initialized defaultScale (normally 1) should be multiplied by (scaleRatio * cameraDist) replacing cameraDist with your camera's default/neutral distance if you want to make the camera distance variable.



scaleRatio is a fixed value as long as the Camera's field of view (cameraFOV) doesn't change.  If you take your field of view cone, and split it in half you get two lines with slopes of Sin(cameraFOV/2) so:

scaleRatio = 2 * Sin(cameraFOV/2)

You'll have to find a value you like for cameraFOV on your own, just make sure it's greater than zero and less than 180.  Around 60 would probably be a good starting point, and since it has a scaleRatio equal to 1 it would allow for more optimized code.



Now, this scale value isn't just the sprite scale, keep in mind that this is the scale of ALL measurements inside the camera's field of view at that distance.  Since our spriteX axis is parallel to the camera's viewing plane we can simply multiply spriteX by scale to get our on screen spriteX coordinate.  The camera is looking directly down what our spriteY axis currently is so it doesn't actually factor into our on screen spriteY coordinate at all.  So where do we get our on screen spriteY value?  Well, there's one axis left we haven't touched this entire time, the Z Axis!  Much like the spriteX axis, it's also parallel to the camera's viewing plane, albeit rotated 90 degrees around our current spriteY axis so a simple multiplication by scale will do for it as well.  If all of the characters are standing on the ground we can assume their Z coordinate is 0 which seems awfully boring, we'll have to move the camera up a bit by giving it it's own Z value (cameraZ, I don't know a good default value) to make things more interesting.  I don't know about you, but I like my positive Z values toward the sky, and negative Z's into the ground so that's how I'll arrange the calculation assuming screen coordinates are such that higher Y values are more toward the bottom of the screen.

spriteX = spriteX * scale
spriteY = (cameraZ - Z) * scale

I know I said these were the on screen coordinates, but there's still one little problem.  The 0,0 location hasn't moved from the center of the battlefield so add half of your screen's width to the x coordinate and half of it's height to the y coordinate to center the battlefield on screen.



Ideally sprites should be drawn in such a way that the spriteX, and spriteY coordinate we have now is at the center of the character's feet.

Weird... I specifically remember that the Italian and Spanish versions of the game had separate strings for items names in Singular and Plural form making them have more lines of text overall.  I know this because I had compensated for it at one point, but apparently it got broken again somewhere along the way...

I tried to make it mostly compatible with all of the official language versions of both Golden Sun, and The Lost Age games as well as a Chinese fan translation that someone sent me a patch for.

Official version I tested with include:
Japanese (J)
English (U)
German (G)
Spanish (S)
French (F)
Italian (I)

Admittedly, I didn't test very thoroughly with non-English versions, and there are some features I know don't work on some language versions (Text editing for the Japanese and Chinese fan translation versions comes to mind)


Additionally, it's partially compatible with Mario Golf Advanced Tour and Mario Tennis Power Tour because Camelot used a modified version of Golden Sun's engine for them, but I only tinkered with the English versions of those.

Great work, Lord Squirtle!

Oh, and I want to cover the basics of the non-assembly scripting format too. Might do that next, which would let me come up with a custom movement script for an NPC.

The editor's idlescripting.ini might help a bit with that.  I also managed to dig a couple old .txt files up from my GS hacking folder that might help, I've attached them.  Looking through my memory locations list, looks like 0x0802F204 is where the pointers to the ASM functions for each scripting command are.

"read" as in the I/O operations to retrieve the data from the hard drive to RAM, yes.

As for the trees being different per game, I can guarantee 100% they had to be changed when translating the games from Japanese to English and there's no reason they shouldn't have been recalculated based on the dialogue in the game.  It would have been computationally inexpensive in the grand scheme of things, probably necessary to achieve the format Golden Sun's engine uses for the Huffman trees, and the only way to get the most efficient compression ratio possible.

I suppose one way of artificially (fake) supporting the theory is seeing how much space is taken up in the ROM when everything is uncompressed.

Remember the text editor GStoolkit?  It did exactly that with the text.  I don't recall off the top of my head exactly how much the size differed, but I do recall that the ROM had to be expanded (Increased in file size) to fit all of the text uncompressed.

I can't theorize about their compile settings since all we have to go off of is the release version, but I can say most definitely that the trees are not random.  At the very least they're ordered specifically to achieve a good compression ratio (this is the primary purpose of Huffman trees).  I can't say for certain if EVERY string in the game was analyzed to see what characters follow other characters most often, but it wouldn't surprise me.  It wouldn't have been terribly computationally expensive to do compared to other things going on during a compile.  I've actually written my own Huffman compression algorithm before, I remember using huge chat logs to generate the Huffman tables.  It took longer to read the chat logs from a hard drive than it did to count how often certain characters follow other characters in them.  Assuming a 100Mb disk read speed (A perfectly reasonable speed even for slower drives these days) it averaged to counting over 10 Million English words (~5 characters per word) each second.

My compression algorithm is essentially using a brute force method, meaning that it keeps trying different combinations until it finds one that works.  It will most probably get the best compression ratio since it starts with small combinations and works its way up, and since it tries every combination until it overflows it should find any that actually work.  There's nothing wrong with it in that regard, but it can be optimized to run faster.

Arguably, the most important thing properly understanding the format would enable is rewriting the Huffman trees to allow the use of more character combinations.  As it is now, each tree only contains the other characters that are needed for the game's current dialogue.  This makes it impossible to follow certain characters with certain other characters.

I had a feeling it was some form of Huffman compression, but couldn't make sense of how the trees were working.  Thank you, I'm glad someone was able to figure it out.