Messages

The end result was made in 2D using resources like scale, hierarchy, sprites, and xy coordinates.  The complexity of the math is so that you can change some of the variables and it will still behave correctly.

If you use the real math behind the effect you want, and make it so all you have to do is move the camera and everything else behaves correctly it's a lot easier to create hundreds of attacks that can move the camera in different ways.

If you fake the math, it probably won't behave correctly and you may have to fake it a hundred different ways to make your hundred different attacks look right.


--edit--

I should also mention that the math may sound complex, but it ended up being less than a dozen lines of code to calculate the screen xy coordinates and scale of a single sprite.  It wasn't particularly hard on the processor either, each individual particle from the magic effect in the image I posted had to go through the same algorithm.  (Though, I think the real Golden Sun's particles were strictly 2D calculations)

Th Y values change.  There's a lot going on there that may not be immediately obvious.

I've remembered more of how I programmed that.

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.

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.  Unfortunately this is where I have trouble remembering the specifics again, I think some of it was based on math from a raycasting engine...  In the end the fact is you'll be doing a simplified 3D to 2D coordinate conversion, hence raycasting engine math.


Remember, Golden Sun uses a 3D coordinate system for movement in towns/dungeons.  I doubt they took an easier route than what I've described to fake the battles which almost actually look 3D.

I really don't have a good grasp on the text compression in Golden Sun at all.  As I recall my compression algorithm essentially brute forced it's way through the recursive trees since I never managed to get a full understanding of how exactly it all worked.

It's probably just a Sine/Cosine equation to calculate their position on screen, like an oval.  It makes perfect sense for rotation like that, and naturally causes the acceleration you're talking about.


I've long since lost the source code I used to create this demonstration, but it was based on Sine/Cosine equations.

Video code?

Code Select Expand

[youtube]https://www.youtube.com/watch?v=bpgtpzEcDjU&list=PLuKVAJH-E9RFS-bx71OFIfNQsBCUCkTOr&index=16[/youtube]

Here is the list of extra BBCode commands on these forums.


This is pretty awesome stuff, it's great to hear the Golden Sun soundtrack getting a high quality remix and the illustrations look fantastic too.

[The most common ones will be implemented.]

Rhetorical: When you play Golden Sun with VBA what settings do you use? The most common ones will be implemented. Consider that even VBA doesn't smooth layers separately.

Me personally, Nearest Neighbor.  I've never been a fan of filters that try to create detail where it didn't exist before, more often than not it just ruins all the work the graphics designers did on the game.  For example that screenshot you posted with the filter applied makes Golden Sun look cartoony, which I don't remember it looking like at all on the GBA.  The shading wouldn't have originally had dithering otherwise bringing me to my next point.  If you look at the grass in your screenshot some of it almost looks like it was meant to be scaled and filtered the way it looks in your image, but other sections still have an obvious checkerboard pattern ruining the effect.  In my opinion it looks like the filter is failing pretty hard on the grass in particular, showing why it shouldn't be applied in the first place.

It's looking pretty convincing so far, I'm impressed with how well you've replicated the game's engine.

*actually tests it out instead of speaking from memory*

Huh, so it's 14x14 pixels per text character.

- Seems like you CAN use the second byte as part of the character width. (Creating impossibly wide characters, and in some cases causing weird glitches)
- The third byte of each character's data starts the third row of pixels.  (The first TWO rows of pixels are always blank.)
- The last two bytes of each character's data are unused. (To make up for the second missing row of pixels)
- The first two bits for each row of pixels are unused. (Making the 14 pixel width limit)
- Any white pixels in the bottom row will not have a shadow.

Just so this knowledge is out there:  The italic font is stored as 1bpp with the first byte of each character representing the width of the character (The first 8 pixels are always blank)  Each character is 16x16 pixels, and takes up 32 bytes.

Using it for an art program, on the other hand, I could see as hella handy...

True enough, doesn't seem like there's been much advancement in that regard as far as standard font formats go though.  There have been proposals to extend them to add color information and more, but as far as I'm aware none of it has been officially implemented yet.

Just remembered something about graphics memory being faster than RAM memory? Try looking up GDDR5, if you want.

Not all computers have dedicated graphics memory though, it's not something you should count on.  Speaking of millions of calculations, even if you're using an underpowered netbook it's likely to be at least 1024x600 resolution, meaning 786432 pixels x 3 color channels = 2.3 million operations minimum, so yes micro-optimizations when rendering graphics are still very relevant.

I'm by no means an expert on how fonts specifically work, but my experience with graphics programming in general has taught me that more transparent pixels = more calculations.  Consider this, to turn a pixel gray all you have to do is write a known value #808080 to it's location memory.  To turn a pixel gray with 50% transparency, you have to read the value currently at that location in memory, perform math to calculate the new color of that pixel, then write that color back to the location in memory.

This calculation looks like:
(Current Red value * transparency) + (New Red value * (1-transparency))
(Current Blue Value * transparency) + (New Blue Value * (1-transparency))
(Current Green value * transparency) + (New Green value * (1-transparency))

Those are a lot of extra operations compared to just overwriting 3 bytes in memory.

Isn't transparency mostly additive?

What?  Maybe I'm missing your definition of additive here, but that seems like the opposite what you want when talking about shadows.  True enough anti-aliasing uses transparency, and since it's likely that individual characters in the font would be pre-rendered to increase performance any transparency would be handled in a similar way.  Still, implementations differ so it's hard to make generalizations like that, and again more transparent pixels = more calculations pretty much no matter how you look at it.

I don't think you can specify transparency either in most standard font formats, it's considered too expensive computationally.  Remember, they can be used to display thousands of characters on screen at once and have to work on the most under-powered computers.  Quick and simple were the key when designing how fonts work.

I don't really see us using a shadowed font on the forums for the same reason, it would be too much for people that are still stuck with crappy computers.

There are font types that can contain color information.  I don't know what they are off the top of my head, but they do exist.

Let's see if this works...

Normal text can be rendered with a shadow.

It has to do with the way the text is anti-aliased to make it appear smoother, see Subpixel rendering.  The font doesn't contain color information to make that happen, it's just the way they get rendered.  Typically modern fonts on computer are stored in a vector format that only describes the shape of each character.

I don't think you can since you wouldn't be able to color it black and the letters white.  Fonts are designed to be one solid color by default.

Sorry I was late with it, I still can't find the file since it was on my previous computer.  As I recall the font was stored as 1-bit per pixel, so trying to read it with the same settings as the other font would have failed since it was... 4-bit I think?...  It was definitely higher.  I want to say the italic font was at around 0x08682000 in The Lost Age... Maybe, maybe not, that may have been the location of the small font...   Either way each character of the font is stored as 16x16 pixels for 32 bytes per character with the first byte's value being the width of the character (The first 8 pixels are always blank)

EDIT:
Found it.  No shadow cause that's generated by code in-game.

I always thought the bank was a bit odd.  I mean you're basically stealing their money when you go back in time and make a withdrawal.

Also, I just saw this comic recently if you want more reason to feel sad about the story of Majora's Mask.

[spoiler=very tall image][/spoiler]

I used a bitmap version of the font, I'm not sure if anyone ever made a windows compatible font out of it.

Small font:


I can't seem to find my file of the larger font right now...

It's unsettling for more reasons than just the fact that the world is doomed over the course of the three days you're forced to play over and over again.  Not only do you witness the apocalypse in Termina if you fail to play the song that turns back time every so often, but each mask you unlock has a tragic back story.  As I recall they're all remnants of heroes that failed in their quests, all of them...  You don't feel like a hero that's making the world a better place as you progress, it's more like a series of tragic checkpoints that only make you more depressed as you unravel the mysteries of a doomed world.  Whether or not you can save the world doesn't seem to matter since all of these tragedies repeat every time you attempt to.  It's definitely the darkest Zelda game to date.

So... Everyone following the Zelda series probably already saw this coming for a while now, but it's official as of the 5th of November.

Having never beaten Majora's Mask (I didn't get the expansion pack for the N64), I'm pretty excited about it.  Although Eiji Aonuma's comments that it's "not going to be just another remake," and him saying "We've spent a lot of time making sure the gameplay experience is smoother than in the original version without taking away from this unique world. I hope those that haven't played the original game, and those of you that played it but gave up mid-way through will take this opportunity to give the new version a try." make me want to play the original game first so I can see what's different.  I wonder how much they plan on changing to make the game more accessible to people that didn't like the original version.  Some of them were turned off from the downsides of being forced to replay the same three days over and over again, but the way time flows and events unfold because of it are a major part of the original game.

Also, intentional or not, the Ben drowned creepypasta famed statue seen in the video still creeps me out, surely Nintendo is aware of it.  "You've met with a terrible fate, haven't you?" I can already see the nightmares.