Hi all,
I'm posting a link to my channel where I'm recreating the GBA Golden Sun engine.
OpenGoldenSun Channel (https://www.youtube.com/channel/UC61ueVBlIniMiJLKrQ_kuzw)
Right now I have these videos up that show where I'm at with the engine.
- 19 Nov 2014: Golden Sun Engine Demo (https://www.youtube.com/watch?v=L0KOyyjdqwM)
- 14 Dec 2014: Golden Sun Engine Update: Graphics Update, Move Psynergy and More! (https://www.youtube.com/watch?v=Y6gC4TfPou0)
- 03 Mar 2015: Golden Sun Engine: Preliminary Battle System (https://www.youtube.com/watch?v=pYEbOrQSAww)
- 04 Apr 2015: Golden Sun Engine: Battle Engine Progress (https://www.youtube.com/watch?v=QMIKE6i5LpM)
- 22 Oct 2015: Golden Sun Engine: Update and Comparison vs GBA in Imil (https://www.youtube.com/watch?v=xvJVbP3mdN0) :!:
It's currently not open source but the intent will be to open source it when it's reached an acceptable point. Subscribe if you'd like, I'll attempt to keep this post updated as I go. This has been made from the ground up with no RPG maker or anything.
I've described more details about the engine in this (https://www.reddit.com/r/GoldenSun/comments/2mvhva/open_golden_sun_an_opensource_golden_sun_engine/) reddit post.
Let me know your thoughts.
Thanks for posting this!
I was thinking about maybe some day creating an open-sourced platform from the ground up based off of Golden Sun's code for people to create Golden Sun-like games... but I wasn't sure if I'd ever go as far as copying all the maps. (I was thinking more about a collection of code-based resources.) However, if it turns out your project is the perfect replacement (which it sounds like it is.) Then I won't need to...
Since I (and Salanewt) have documented quite a bit about GS2, I guess I'll eventually look into seeing how your project is organized compared to it, and check for consistencies as well. :)
Open Golden Sun! Just like "Openmw"! Like a dream come true!
I would pay good money for a decent RPG maker. I'm serious, too.
Though, for my own purposes, I would need 3D support and a Z-Axis to create something with an overworld style similar to Grandia. 3D Environments with 2D sprites. https://www.youtube.com/watch?v=sUUHBFN3QL4
I'd probably need for the battle system to be modifiable, so I could make something similar to Grandia, too.
Why am I basically asking for an Open-Source Grandia-maker on a Golden Sun Forum? >_<
I guess a guy could dream when wanting to make his own original RPG with inspired mechanics...
Question - how editable will this be? Would we be able to add additional stats, so as to give psynergy stat support? How much control will we have over things like critical hit rates, unleash rates, and damage formulas?
Quote from: Lishy on 15, December, 2014, 08:38:15 PM
I would pay good money for a decent RPG maker. I'm serious, too.
Though, for my own purposes, I would need 3D support and a Z-Axis to create something with an overworld style similar to Grandia. 3D Environments with 2D sprites. https://www.youtube.com/watch?v=sUUHBFN3QL4
I'd probably need for the battle system to be modifiable, so I could make something similar to Grandia, too.
Why am I basically asking for an Open-Source Grandia-maker on a Golden Sun Forum? >_<
I guess a guy could dream when wanting to make his own original RPG with inspired mechanics...
I'm really not the best person to do something like that and I really wouldn't have the time, sorry (also you can't afford me :happy: ). I'm really just making this because they're my favorite games of all time.
Quote from: Rolina on 15, December, 2014, 09:09:41 PM
Question - how editable will this be? Would we be able to add additional stats, so as to give psynergy stat support? How much control will we have over things like critical hit rates, unleash rates, and damage formulas?
You would be able to do whatever you want in theory. I will most likely create all the damage and stat calculations off what the game currently does and then modify from there.
@3D support: Is it even possible to take Golden Sun's 2D maps and make them rotatable as if they were 3D? Even if it was a slight rotation like an earthquake. (Possibly using the height map in part of the equation of-course.)
It may or may not be tricky/ugly/feasible, but still, it was an idea.... You'd use sin and cos for sure. But just in-case, has anyone seen anybody try something like that?
@Ugly: Imagine how houses would work, you'd need to fix the sides and back, obviously.
QuoteI'm really not the best person to do something like that
Just to make sure, does some of that time you would need have to go into figuring out how to go about it, or would you already have an idea, but the work to do it is difficult?
Will we be able to manage things such as accuracy, evasion, and move priority? Would we be capable of handling Criticals and Unleashes as separate entities, or would they be folded into a single thing like they were in Dark Dawn?
I like how you guys are already trying to hack an un-built project. :happy:
@Rolina, the thing with coding something from the ground up is, you can do anything you want.
@Fox, I'm really just going to focus on rebuilding the GBA engine as-is. I'm sure adding a pseudo 3D affect would be cool, but I'm not looking to reinvent the style of the game.
Looks sweet, you have the full attention of all members of this board!!!
This is the greatest news seen on this site in years!! I'd almost gave up on the idea of a golden sun Fan game.
WOW! :happy: :heart:
It's looking pretty convincing so far, I'm impressed with how well you've replicated the game's engine.
Quote from: MaxiPower on 22, December, 2014, 06:03:11 PM
Looks sweet, you have the full attention of all members of this board!!!
This is the greatest news seen on this site in years!! I'd almost gave up on the idea of a golden sun Fan game.
WOW! :happy: :heart:
Thanks! I look forward to seeing where this goes.
Quote from: Atrius on 22, December, 2014, 07:08:03 PM
It's looking pretty convincing so far, I'm impressed with how well you've replicated the game's engine.
I take that as a huge compliment, especially coming from you, so thank-you.
Quote@Fox, I'm really just going to focus on rebuilding the GBA engine as-is. I'm sure adding a pseudo 3D affect would be cool, but I'm not looking to reinvent the style of the game.
Okay, fair enough. Sticking to just the Golden Sun engine, is probably what I would have done as the focus point as well? ; And then when the GBA project would be complete, perhaps look to see what Dark Dawn had to offer, and implement optional things from there, but I dunno.
Looking good so far. Have you worked on the battle system yet?
Oh and...
Quote@Rolina, the thing with coding something from the ground up is, you can do anything you want.
Well, you are still limited by the programming language and hardware, but that's little to be concerned about considering how limited hacking the GBA was. (It's like hacking the GBA is only worth it for collecting data? That, and maybe translations/difficulty hacks, anything minor.)
Quote from: Fox on 23, December, 2014, 08:02:38 AM
Looking good so far. Have you worked on the battle system yet?
Not yet, I think that will come later. Sorry, I know it's one of the more interesting parts but it's also one of the hardest. I'm comfortable with the structure I've built for doing field psynergy. While doing Move & Growth I think I was able to come up with a pretty decent structure so now it's just a matter of finishing up a bunch of the field psynergies. I'll probably focus on a couple more field related items such as: jumping, pushing, and cliff-edge sliding.
Once I'm comfortable with those items I'll move onto to either the world map or battle system. Once those are in a good spot, I'll probably do a major code refactor.
Here is a screenshot of the Class View for the engine (large image), this is completely subject to change and I'm posting this mostly because you seemed interested: http://i.imgur.com/xqeGWVm.png
That's fine. As a small hint, though, I believe the game uses two angle values that can be found at addresses 0x02030034 and 0x02030036. So I don't imagine that setting up the base battle system would be too difficult (Basically skin and bones), but actually making it a playable feature with properly working animations/etc might take a whole lot more work.
The World Map should be pretty easy...
That image looks great! Keep up the good work.
Very nice work! I am very impressed! :happy:
Looks like you are using xna, right? C# is a lovely language.
That's a very hard and professional work and you have already done lot of stuff.
Can't wait to see the source!! :happy:
I'd love to see some behind the scenes stuff, so as to better see what bit of code corresponds to what. Or, alternatively, if there's a UI functionality built into it like with Atrius' Editor, I'd like to see that.
Same. I'd like to know how the map data is done, myself. What is this TileAndHexUtilityForm?
-Is it just 16x16 tiles without the four split 8x8 tiles like how the game works?
-Are the tiles done in 16bpp? Without an indexed pixel format?
I'm interested in how the field effects are done. I'd love to add more (say, fireball functionality from DD), so seeing how Move and Growth were handled would be kinda neat.
I imagine the basics of field effects are simple enough to understand... but as for the entirety, probably plenty of work to implement? (You have to also remember the less obvious things like how Douse will do snowflakes in cold places.)
-You generate the graphics in front of the character.
Something like this... (If assuming facing right is a 0 degree angle.)
Utility_x = PC_x + (distance * cos(PC_angle))
Utility_y = PC_y + (distance * sin(PC_angle))
-Interacting with objects is likely tile based, so x/16 and y/16 (Or was it /8 each?) or something like that... And different utilities measure out different distances in tiles.
Frost could work 1 tile away, Move could work 2 tiles away, for example.
Yeah - casting a fireball effect into, say, a waterfall would probably require a check to trigger its own animation variant or something. Didn't we create a patch to allow for 8-directional utility casting? I imagine working that into the game would be a pretty good idea as well.
I want to see if this is coming straight from a program, or if he's developing a UI kind of like what atrius did. Plus, knowing what programs he's using would be a good thing for when we go in to have fun with it.
This is looking very good, and I hope you'll keep the project going (@OpenGoldenSun). It appears to be a very faithful replica of the game engine, to the point that I believe you have a pretty good grasp of how the game works. So with that in mind, I don't feel the need to point anything out - just keep up the good work!
However, I have to respectfully disagree about the graphics filter you used in the video... nothing wrong with it in itself, but I don't think it makes the GBA pixel graphics look better.
Oh, and like others here I'm interested in a few more details about how you're making this. Saying you're building it "from the ground up" isn't particularly telling. What programming language and other resources are you using?
@Rolina: Open source generally just means the source code is available and unprotected, but I guess we should be able to expect some kind of editor, as otherwise there wouldn't be much of any point to doing this. In response to "can we do X", anything can be done, just as nearly anything can be done on the GBA, except now with fewer restrictions and the advantage of a conventional programming language.
QuoteWhat programming language and other resources are you using?
Not sure, but did you read this? (Link in first post.)
https://www.reddit.com/r/GoldenSun/comments/2mvhva/open_golden_sun_an_opensource_golden_sun_engine/
More specifically:
QuoteWhen will this be open-sourced?
So, right now it's coded on DirectX9 with C# using XNA. The plan is to get it over to MonoGame and SharpDX. Before this happens I still have a few iterations of game code architecture that I need to figure out. Game architecture is always tricky, it's pretty easy for it to turn into hack on top of hack. I don't want to open-source it that way. I will attempt to get it to a respectable stage of development with a clean architecture and then open-source it.
You are welcome. :)
(I believe I was going to ask that same question earlier...(probably near the time the topic was made?), but then I wanted to make sure it wasn't answered... So it was good I checked. :) )
Hrk, sorry about that. Yes, I did read the stuff in the link, but I skimmed the FAQ since that wasn't the question I was looking for. Thanks for clearing that up.
Everything is still in early stages. There is no UI for this engine because the project is nowhere near that stage. Right now configuration of maps and stuff is done through a separate code project (GoldenSun.Game.Definitions).
Currently it uses an event engine with conditions and actions. I.e. if all condition requirements are met then the actions are run. This is something that I've designed to be quite configurable. For example you could basically configure events on a map such as:
If controlled player intersects a bounding rectangle with the specified absolute bounds then...
Suspend control of player character
Show dialog window
Wait for dialog window close
Resume control of player character
You can see that structure in the class hierarchy I posted.
I do sort-of store tile based data for the maps, but probably not how you're thinking. All the maps are .png files with transparency.
There are utilities that I've created to better help me translate accurately and efficiently things from the actual game to the engine. That is where something like the TileAndHexUtilityForm comes in. An example of how that form is used is: I want to replicate the exact water effects that Vale has. Meaning, the exact animations at the exact same spots. Obviously doing this manually is tedious. So I can do a memory dump from VBA and then it will read all the relevant tiles that I want (I click on the tiles to tell it which ones I want) and then it will generate the code based on whether the tile is flipped vertically or horizontally etc...
The field psynergy effects are all written manually. The positioning of the Move hand etc... is all calculated with vectors and such. So in theory you could (if you allowed) cast move from really far and the hand would animate to the pillar (I could maybe post a video of this for fun).
I also tweaked the smoothing algorithm because I know some people weren't a fan. I think the main thing was what it did to Felix's face (mostly the eyes). Here is what the new version looks like, as you can see the eyes are much better.
(http://i.imgur.com/lPAP1Rp.png)
As I mentioned in the comments of the vid you showcased that in, it might be better if you have a staggered blending. For example:
Layer 1 affects the background assets
Layer 2 affects the sprites
Layer 3 affects the menus and text boxes
For me, I'd probably turn layers 1 and 2 on, but would prefer to have layer 3 off. This would allow people to toggle bits and pieces to get a look they see as being ideal for their tastes. Consider the different layers for a future update. ^-^
Id prefer it with no smoothing whatsoever tho I can see why people may like it. So the option to toggle it all off would be sweet.
How much work is there in adding each separate psyngery? Must be a pain with soooo many of them yet rewarding when they finally work.
Quote from: MaxiPower on 07, January, 2015, 09:24:28 AM
Id prefer it with no smoothing whatsoever tho I can see why people may like it. So the option to toggle it all off would be sweet.
No smoothing is default.
What looks good and what doesn't is highly subjective, and considering this is just a recreation of the engine I don't think you should concern yourself too much with it. Maybe support higher resolution graphics, for those who would be willing to create those graphics. Personally I think visual improvements go beyond the scope of this project, but it's not my project so...
Quote from: MaxiPower on 07, January, 2015, 09:24:28 AM
Id prefer it with no smoothing whatsoever tho I can see why people may like it. So the option to toggle it all off would be sweet.
How much work is there in adding each separate psyngery? Must be a pain with soooo many of them yet rewarding when they finally work.
It already has a toggle - right now it's all or nothing. I was hoping for a tiered toggle, so that we can pick and choose what we want smoothed and not smoothed.
I also second support for higher res graphics. Say what you want about Dark Dawn, it's icons were gorgeous. I think right now, however, it may be a better idea to focus on getting the core of the game done, and then working on graphical addons like smoothing and high-res graphics for later.
Guys, it's important to realize that this is a
GBA engine clone. There will be no higher resolution graphics support. Everything is being drawn to a 240x160 (native GBA resolution) buffer and then scaled either according to two variations of the xBR filter (square vs rounded) or no interpolation (nearest neighbor). The menuing icons and screens will be copied from the GBA games with some minor changes.
Performing smoothing on separate layers is not ideal for a few reasons:
- FPS (You're looking at approximately 4-5 different stages where a shader effect will need to be rendered per frame)
- Complexity (Layers would need to be able to render over top of other layers with different shader settings)
- Don't agree on it's usefulness
- Doesn't seem worth the time and effort
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.
Well, I certainly don't use smoothing. The most I used on VBA was the speed increase function.
Quoteit's important to realize that this is a GBA engine clone. There will be no higher resolution graphics support
So does this mean no Dark Dawn icons? Or would they just have to be graphically downgraded?
---
Smoothing? Not even sure where that setting is on VBA... (Render Method?) So it's likely I use their default setting.
Quote from: OpenGoldenSun on 10, January, 2015, 02:12:46 AMRhetorical: 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.
Yeah, maybe Nearest Neighbor is the way to go. I still wonder about minor smoothing though. Basically to the point where you *barely* notice a difference, but you do if you look carefully/zoom in some more. Although, doing it at that point might render it pointless... so yeah.
Quote from: OpenGoldenSun on 10, January, 2015, 02:12:46 AM
Guys, it's important to realize that this is a GBA engine clone. There will be no higher resolution graphics support. Everything is being drawn to a 240x160 (native GBA resolution) buffer and then scaled either according to two variations of the xBR filter (square vs rounded) or no interpolation (nearest neighbor). The menuing icons and screens will be copied from the GBA games with some minor changes.
I find it odd that you point this out after deciding to include a function exclusive to emulators, but oh well. If someone wanted higher resolution, they could modify the engine to support it after you release it to the public. I guess that's the beauty of open source.
My stance on smoothing is much the same as what Atrius wrote, those pixels won't look better no matter what you do with them - the graphical information just isn't there. But it doesn't hurt to have the option, since you added it already.
QuoteI find it odd that you point this out after deciding to include a function exclusive to emulators, but oh well.
And the GBA didn't allow you to have a bigger screen, did it? (Assuming that the emulators added those functions due to full screen looking a bit blocky.)
Aside from that, GBA does support Rotation and Scaling without the filters.... I know GS has a zoom-out with the L button on the world map, but I haven't checked how that was done. (Were there some cutscenes that involve being zoomed in? Haven't checked those either...) My bet is that neither one use filters?
I'm not trying to argue that smoothing is better, nor am I trying to convince you. It's all personal preference. Personally, if I'm playing at 5X or 4X normal resolution, I like the filter. If you don't like it that's perfectly fine.
This conversation has just become arguing over personal opinions and is not constructive. Everyone should already be aware that the filter is not forced, it is easy to turn off.
Let's shift our focus away from discussing smoothing and more towards constructive dialog.
So on that note, I'm currently working on getting the battle system skeleton up and running. I'm trying to get that pseudo-3D effect that happens while the characters move across the screen (as if the camera is rotating around them). It seems like there is some acceleration variable being taken into account as the character approaches the right side of the screen and then moves left (notice how the character will almost pause in one spot before coming back to the left).
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.
(http://img.photobucket.com/albums/v698/AtriusV/Games/Golden%20Sun%20Project/BattleRotate.gif)
Oh, that pic reminds me. Will we be able to have more enemy sprites on screen? You said it's going to emulate what the VBA can do... but I don't see why we should limit ourselves to the video memory of the GBA. For example, if you want to fight four enemy adepts, you can't - a graphical glitch will occur on the fourth. Try creating a fight against all four of the proxians to see what I mean. I'm pretty sure that just about everyone's gonna want to see a full team vs full team match, and would definitely try it if they could. The best thing about making something for PC, by far, is going to be the fact that you can do more than what the original hardware could pull off.
@Atrius, thanks for that. That should be enough for me to figure it out.
@Rolina, yeah it will for sure handle full party vs. full party. For the enemies I think it will basically just come down to what screen space is available, I don't see any issue with allowing more enemies than normal so long as they fit properly.
Do you have battle examples up yet? I'd like to see the effect of the screen smoothing there, since the art style is a bit different.
Edit: Also, been meaning to ask this. For those of us who wish to add additional statistical values to the games, will we be able to increase the screen size to compensate for the larger menus we'll have to do (to, say, the resolution on a single screen of the DS for instance), or are you committed to the whole VBA-only thing? Would you have a solution in place in such an instance, perhaps to allow for some menu scrolling so that we can get all the data to the player?
Quote from: Rolina on 12, January, 2015, 08:53:57 PM
Do you have battle examples up yet? I'd like to see the effect of the screen smoothing there, since the art style is a bit different.
Edit: Also, been meaning to ask this. For those of us who wish to add additional statistical values to the games, will we be able to increase the screen size to compensate for the larger menus we'll have to do (to, say, the resolution on a single screen of the DS for instance), or are you committed to the whole VBA-only thing? Would you have a solution in place in such an instance, perhaps to allow for some menu scrolling so that we can get all the data to the player?
I'll be posting a video for the battle system hopefully within the next couple weeks.
For your second set of questions, here is what the engine looks like when it's run at an internal game resolution of 256x192 (Nintendo DS):
(http://i.imgur.com/adzRw6R.png) (http://i.imgur.com/q2w1L2k.png)
As you can see the menus are larger than normal. Also, you can see more of the map in the second image.
Essentially I can adjust the internal game resolution to whatever I want. Which basically will just show more map, and make more dead space in the menus.
good
Cant wait for the video. I need a time machine! :)
Quote from: OpenGoldenSun on 12, January, 2015, 10:44:29 PM
Quote from: Rolina on 12, January, 2015, 08:53:57 PM
Do you have battle examples up yet? I'd like to see the effect of the screen smoothing there, since the art style is a bit different.
Edit: Also, been meaning to ask this. For those of us who wish to add additional statistical values to the games, will we be able to increase the screen size to compensate for the larger menus we'll have to do (to, say, the resolution on a single screen of the DS for instance), or are you committed to the whole VBA-only thing? Would you have a solution in place in such an instance, perhaps to allow for some menu scrolling so that we can get all the data to the player?
I'll be posting a video for the battle system hopefully within the next couple weeks.
For your second set of questions, here is what the engine looks like when it's run at an internal game resolution of 256x192 (Nintendo DS):
(http://i.imgur.com/adzRw6R.png) (http://i.imgur.com/q2w1L2k.png)
As you can see the menus are larger than normal. Also, you can see more of the map in the second image.
Essentially I can adjust the internal game resolution to whatever I want. Which basically will just show more map, and make more dead space in the menus.
Awesome! Thanks! Being able to to generate more space is good for when we run out.
Maybe put a limit on it, could be interesting... some game engines calculate a scale factor based on the stage and viewport width and apply it in the sprites size.
----------------
Looking at that Atrius gif, it seems that Y position of the heroes don't change. The sprite texture and hierarchy change with X variation. The X speed variation at this animation seems to be cos/sinusoidal with zeros near the borders and peaks at the center. But I don't know about your resources, but I think that an easeInOut animation can substitute the cos/sin functions once you call it everytime you need to vary X.
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 (http://lodev.org/cgtutor/raycasting.html)... 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.
Ok, I don't know how golden sun engine works. But this scene can be made in 2D using resources like scale, hierarchy, sprites texture change and xy coordinates. The effect will be the same and, maybe, done in an easier way. Depending how his engine treats the texture atlas, he only has to concern about the 'real' xy position of the char on the screen making animations become easier to be made.
--------- edit
To make this scene, you had to adapt to the golden sun base engine, but I don't think that's the way the programmers took. Perhaps they used a framework.
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)
Actually, with 2d calcs, you won't need to do hundreds of attacks since you create a standard, so you can pass just few parameters (or only the type of attack... physical, summon, psy... then the algorithm does the animation). That's how recent 2D engines do these things, like starling and cocos2d. They are told 'easy to use' cause they treat things in this way.
I know this math isn't complex, but once you can avoid, why not? And I don't think this is fake math, It's just another way to deal with this.
Of course, this things I'm talking is only possible if his engine gives support to it.
Um... Would it be worth having both methods?
I could see it useful for educational purposes, and so that people have more choices. (Including even altering the formula itself.) :) (Assuming it's not as hard as it sounds, and the method differs enough for it to be worth considering.)
One version could be Golden Sun Original Method, the other version could be "WIP" whatever you want it to be.
---
QuoteTo 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)
I remember seeing two angle values in RAM.... But you make it sound like there's just one?
A suggestion would be use the Tiled Map Editor http://www.mapeditor.org/ (http://www.mapeditor.org/), or something like it. It's very simple to use and exports files like JSON, CSV, XML etc, that you can adapt your engine to use.
I searched at google images 'golden sun tileset', got this http://img.photobucket.com/albums/v48/psgels/psgels-Ruins-Exterior-01.png (http://img.photobucket.com/albums/v48/psgels/psgels-Ruins-Exterior-01.png), set white as transparent color and easily made the image below.It will be very nice to build maps. And It's free! An example of JSON file is also attached.
(http://s27.postimg.org/xjhosqcgz/Capture.png)
It's almost a month later. How's the project been going?
Nothing to report, sadly. I've been really busy.
A video on the battle system progress (preliminary). (http://"https://www.youtube.com/watch?v=pYEbOrQSAww")
Quote from: OpenGoldenSun on 01, March, 2015, 11:55:10 PM
A video on the battle system progress (preliminary). (http://"https://www.youtube.com/watch?v=pYEbOrQSAww")
youtube tag [ youtube] [/youtube]
And very nice!
Great stuff man. Nailed it.
That's a good start. It's also nice to see progress again.
Quote from: Atrius on 14, January, 2015, 07:30:08 PM
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 (http://lodev.org/cgtutor/raycasting.html)... 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.
It would definitely be useful to see what you built for that.
I responded to your PM, but I'll post it here too cause it's good information other people might want as well.
Quote from: OpenGoldenSun on 02, March, 2015, 10:42:34 PM
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.
QuoteThe 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.
(http://img.photobucket.com/albums/v698/AtriusV/Games/Golden%20Sun%20Project/GS_BattleCamera_01.png)
QuoteTo 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.
(http://img.photobucket.com/albums/v698/AtriusV/Games/Golden%20Sun%20Project/GS_BattleCamera_02.png)
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.
(http://img.photobucket.com/albums/v698/AtriusV/Games/Golden%20Sun%20Project/GS_BattleCamera_03.png)
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.
Hey Atrius,
Thanks for the reply. I finally got around to implementing the method you discussed (your instructions helped a lot). You may have seen my other video of my preliminary battle system where I use a technique called "Billboarding" to attempt to achieve the same effect. I'm basically comparing the two methods for ease of use, flexibility etc...
Here is yours:
(http://img.photobucket.com/albums/v698/AtriusV/Games/Golden%20Sun%20Project/BattleRotate.gif)
Here is mine (note: I'm not doing animations of them at this point, it's just still images):
(http://i.imgur.com/owISw4u.gif)
I have a couple questions for you, I'm hoping you can help me out (this is specific to your method):
- 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.
- 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'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.
- What camera rotation speed do you use? I go 1 degree every frame @ 60fps.
How is Sheba's height calculated?
(http://i.imgur.com/qi4ciSB.png)
Approximate camera angle from image above in my engine:
(http://i.imgur.com/IYJMqJX.png)
Pretty cool to have this implemented. Although it'll probably be a pain to make that start-up rotation and zoom the actual game does when a battle starts.
Great work man.
Really nice.
- 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.
Quote from: Atrius on 13, March, 2015, 05:06:16 PMNow, 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.
One thing I noticed in the games is that the camera has different speeds it can move. What I figure should be done is a recording of the original games in motion - find the rate of rotation for the opening of battle, the swivel between parties attacking, and the speed for "uber moves" like spark plasma and grand gaia for starters. I'm pretty sure those are three different speeds. From there, it should be easier to figure out simply by seeing how many frames it takes to turn the X degrees it turns.
@Atrius, thanks for the quick reply, that all makes sense. I'm thinking that I'll have possibly 2 different scale numbers to get this as close as possible to the original. A defaultScale like you've described (starting at 1.0) and a positionalScale, based on where they are in the party position. So for example if Sheba was in position 2 (second position looking from the front) it might be 0.90 - 0.05 or something. I'll see what I come up with, getting pretty close to the battle engine being demoable.
You've mentioned that your method is not really based on the code the engine uses, but that's perfectly fine. You've done the legwork to make a simulation that is pretty damn close. I can tweak stuff to see how close it can be for this.
@Rolina, you raise a good point that I've been meaning to bring up. 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. I know I can recreate it using the editor but if someone already has something that's even better. If would really help for field psynergy and battle psynergy.
@Luna_blade, MaxiPower, thanks guys.
Quote from: OpenGoldenSun on 03, April, 2015, 10:03:35 PMDoes 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 (http://forum.goldensunhacking.net/index.php?topic=566.0), and the TLA equivalent is here (http://forum.goldensunhacking.net/index.php?topic=565.0). (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.
Here's where I'm at with the battle engine:
Hopefully I can make the next video an actual battle.
For the gifs at the top of the page:
The background is faster in Atrius' rotation.
The sprites are faster in OGS' rotation.
03000030 = Battle data stuff ==>
02030034 = Up/Down rotation
02030036 = Left/Right rotation
030000B0 = Camera destination data pointer ==>
02031090 = Left/Right rotation destination
02031094 = Frames to rotate for.
If you compare rot. against the rot. dest., you'll probably notice they're 0xF off, so it likely rotations to the +/-0xF boundary.
The left/right rotation seems to match with this:
0x4000 = During turn selections
0x2000 = Directly after turn selection
0x1500, 0x1C00, 0x2400, 0x2B00 = 1st - 4th PCs
= Actual rotation is based on PC's x/y position, and not slot. (ex: What direction would you be facing if you were looking at the PC from the center?)
*Looks at 08011EA0C function, which is for Ability Type Values 0x2 and 0xF.*
+0xFFFFE000
+0x6000 if enemy
And 0x7FFF
+0xFFFFE000
+= >>0x1F
>> 1
+0x2000
0x2400 = PC use healing psynergy.
Defend/Flee/some Summons do not altar rotation? (Stays at 0x2000)
QuoteOne thing I noticed in the games is that the camera has different speeds it can move. What I figure should be done is a recording of the original games in motion - find the rate of rotation for the opening of battle, the swivel between parties attacking, and the speed for "uber moves" like spark plasma and grand gaia for starters. I'm pretty sure those are three different speeds. From there, it should be easier to figure out simply by seeing how many frames it takes to turn the X degrees it turns.
Most rotation seems to be based on 0x3C frames, I think. (60 frames)
Did not check opening of battle, though.
--
030000A8 = Opening entrance stuff (Only points to just one 32-bit.) ==>
03001380 = Frame counter for opening entrance. Edit this to 0 during the opening, and you'll see the opening entrance happen again.
The openng entrance might be based on rotation for 0x50 (80) frames, ((frame * 0x168) + 0xAF80)
The scaling should be (0xB4 - frame). 0xB4 = 180, so 180%... after the 80 frames, should be 0x64 (100%)...
and the party stats box comes down for 0x20 (32) frames, but starting at frame 0x14 (20). (03001122 changes Y location of this box, but it gets updated every frame, so don't edit & test.)
I think the black transition graphic also animates 1 frame per pixel. Loking at height.... 80*2=160 might be the boundary, however, the area is 120, so the last 20 frames would not matter?
I wonder if 030000AC is camera related or not.
Does anyone know where I could find all the sound effects that Golden Sun uses? Like opening the menu, cancelling the menu, using psynergy, etc...
I have the OST, but now I need the game's sound effects.
Quote from: OpenGoldenSun on 08, April, 2015, 12:20:29 PM
Does anyone know where I could find all the sound effects that Golden Sun uses? Like opening the menu, cancelling the menu, using psynergy, etc...
I have the OST, but now I need the game's sound effects.
I might have them. I will have a look and if so, upload them for you!
EDIT:
https://www.sendspace.com/file/u8des4
Hope its all your looking.
Quote from: MaxiPower on 08, April, 2015, 12:45:42 PM
Quote from: OpenGoldenSun on 08, April, 2015, 12:20:29 PM
Does anyone know where I could find all the sound effects that Golden Sun uses? Like opening the menu, cancelling the menu, using psynergy, etc...
I have the OST, but now I need the game's sound effects.
I might have them. I will have a look and if so, upload them for you!
EDIT:
https://www.sendspace.com/file/u8des4
Hope its all your looking.
Thanks. I ended up doing it the tedious way by recording the applicable audio channels from VBA-M before seeing this. :sad:
Lol i posted 25 mins or so after you :P
Least you have them now tho man, thats the main thing... now get back to work!! ;)
Wasn't expecting such a quick response.
Quotenow get back to work!! ;)
I have some cool stuff to show...
Warping around a map with Alex:
Wow. Even though I haven't really been following this much, I have to say that I really like how you handled the warp spell. Been thinking of experimenting with a hacked utility for GS, and I think I'd want it to be kind of like how yours is set up.
Nice work!
Looks awesome!
2 PP? Hmm... Maybe.
I take it this works anywhere as long as the locations are visible on the screen?
Perhaps you should have tried it as an L/R shortcut as well?
Do you plan on also having the field psynergy that Alex used just outside of Venus Lighthouse on the guards...? (Drench?/Deluge?)
That's awsome man. Some neat puzzels could be implemented with that and even could used with other pysngery or be used to add in new puzzels to past areas. It would be a neat near end game psyngry to get.
QuoteDo you plan on also having the field psynergy that Alex used just outside of Venus Lighthouse on the guards...? (Drench?/Deluge?)
Shh... spoilers. :happy:
Amazing progress!
I can't help noticing that some tiles on the map don't connect wel and other minor stuff, though. But still cool.
Also, it seems there are fixed points of where you can warp to... so, is that going to change or how does it work?
Quote from: Luna_blade on 10, April, 2015, 11:29:14 AM
I can't help noticing that some tiles on the map don't connect wel and other minor stuff, though.
Not really sure what to tell you, those land masses are direct copies from the game, I didn't make them. I think I know what you're talking about, where the edges meet the center pattern looks strange, but that's how they have it in the game.
Quote from: Luna_blade on 10, April, 2015, 11:29:14 AM
Also, it seems there are fixed points of where you can warp to... so, is that going to change or how does it work?
Yes, there are fixed points of where you can warp, if that point is fully visible on the screen, it will show up as a selectable destination.
Awesome! Very very nice!
Quote from: OpenGoldenSun on 10, April, 2015, 12:24:21 PM
Not really sure what to tell you, those land masses are direct copies from the game, I didn't make them. I think I know what you're talking about, where the edges meet the center pattern looks strange, but that's how they have it in the game.
Oh... I checked it. You're right. I think it looks pretty shitty in-game if you look close enough.
I'm going to have a mental breakdown... (not really :happy:)
That's a really smart way of doing that! Nice! It's great to see we have new field spells~
@OpenGoldenSun
How long is the process from choosing what psyngery to implement to >>>> Having it inserted in engine? Like, does the thought of adding 100s of psyngery seem daunting? I would imagine it would be yet rewarding when it works and comes together. I am so envious of your ability. :sad:
Quote from: MaxiPower on 11, April, 2015, 07:41:54 PM
@OpenGoldenSun
How long is the process from choosing what psyngery to implement to >>>> Having it inserted in engine? Like, does the thought of adding 100s of psyngery seem daunting? I would imagine it would be yet rewarding when it works and comes together.
It can take a few hours per psynergy, depending on the psynergy's complexity. Creating all the field psynergies will take a while (let alone the battle ones). But, that's just part of it. The nice thing is that I can kind of jump around to other stuff when I'm getting tired of one thing.
Quote from: MaxiPower on 11, April, 2015, 07:41:54 PM
I am so envious of your ability. :sad:
I'm a programmer by day, which helps a lot. But I'm self taught, no reason you can't be. :happy:
I did a course a few years ago on basic coding and it went over my head and that was basic stuff. Whenever the code is released, I will have a look at it and try and determine what does what, documenting on the way. Id be happy if I could make small alterations and maybe add new psyngery by using an existing one as a template. That said hopefully when it is all done, the engine is somewhat easy to use for dummies such as myself. :P
Hot damn... This is amazing. I looked decent back on page two, and now I'm completely excited.
This makes me want to make the game that Dark Dawn should of been... This calls for a literary analysis of each character so I can properly write for each character who would be recurring. Or, even a version of the first game from the perspective of Felix.
Will it ever happen, though...? We'll see.
But regardless, looks like I have some motivation to drive my wish to learn C#.
Edit: After reading your reddit post, I realize this is exactly why you're making this engine. Cool beans.
QuoteHot damn... This is amazing. I looked decent back on page two, and now I'm completely excited.
Yep! What would you think about a Golden Sun project on the Hololens? (Hololens is Microsoft's project that will run Windows 10... which will be released this year (PROBABLY! But dunno.. they weren't specific enough on a release date, I don't think.)
(Might make more sense on the Oculus, but still... I wonder if the Hololens could be a VR as well as augmented reality...
For augmented:
-We could pretend like we're adepts ourselves, and special effects could happen in real life, maybe.
-Or we could just control a character on a real-life playing field. (Which makes even more sense, since you can't go teleporting yourself.)
Anyway, you could look up for one of Microsoft's conferences on the Hololens, or you could wait til the end of the month to see their latest conference.. (Or whatever.)
Edit again: Imagine being able to touch 3D: http://mashable.com/2015/04/04/tablet-revolution-3d/ - I can imagine eating dinner on one of these. Imagine a bowl of soup. Heheh... Don't think that would work too well, though. Unless the device had (self-cleaning/non-stick)/anti-heat/etc. functionality.
Quote from: Menaus on 12, April, 2015, 09:07:57 PM
But regardless, looks like I have some motivation to drive my wish to learn C#.
There's a nice C# course by Microsoft starting this month at edx.org, look here. (https://www.edx.org/course/programming-c-microsoft-dev204x)
I'm trying to learn XNA to don't get completely lost.
Oh cool! I don't think taking time-defined courses is for me, but thanks anyway. Say? Are they going to record their session for later viewing? (For those who don't enroll?)
(Edit: I just realized April 7th was about a week ago. :p)
Things to remember about programming in general: (And the three main speed-ups that might not be obvious of which I'm glad I learned about at one time.)
-Need to load a lot of data from a file? Consider using I/O file method to load to a buffer. (Direct reads via the non-I/O method is too slow.)
-Need to display graphics? SetPixel (Atleast for VB.Net) would be way too slow, so put your pixel data in a buffer, and attach that to a bitmap object.
-Need to display a bunch of strings? Concatenating them over and over might be too slow due to repointering, so use StringBuilder.
As for those beginning with a new language:
-Understand syntax (Mainly the concept of "if then" and do/while; but others may be nice to know as well.)
-Understand variables, and how they're defined/used. ; byte, short, int, long are 8, 16, 32, 64 bit signed types, for example.
-Understand functions, and how they're called/used. ; You can call with arguments, and have a value returned.
Quote from: jjppof on 13, April, 2015, 07:41:02 AM
I'm trying to learn XNA to don't get completely lost.
Learn MonoGame (http://"http://www.monogame.net/") instead, since that is where this will go and XNA is dead.
@Fox
I really don't think that virtual reality will fit in the scope of this project. It's cool, yeah, but it just doesn't fit the genre, nor will it even add to the experience in a meaningful way, imo. We'd have to completely change the game from the ground up, and I think that we'd be doing the same thing Camelot did with Dark Dawn in the end, except far worse.
@OpenGoldenSun
Okay, fair enough, I'll check that out.
Quote from: OpenGoldenSun on 13, April, 2015, 02:16:04 PM
Quote from: jjppof on 13, April, 2015, 07:41:02 AM
I'm trying to learn XNA to don't get completely lost.
Learn MonoGame (http://"http://www.monogame.net/") instead, since that is where this will go and XNA is dead.
Nice! Thanks for the hint!
Quote from: Fox on 13, April, 2015, 08:02:25 AM
Oh cool! I don't think taking time-defined courses is for me, but thanks anyway. Say? Are they going to record their session for later viewing? (For those who don't enroll?)
(Edit: I just realized April 7th was about a week ago. :p)
You still can enroll and you can access the material without worry about time. Time is just for grading.
@MonoGames: Thanks for letting us know, I guess I could take a look.
QuoteI really don't think that virtual reality will fit in the scope of this project. It's cool, yeah, but it just doesn't fit the genre, nor will it even add to the experience in a meaningful way, imo. We'd have to completely change the game from the ground up, and I think that we'd be doing the same thing Camelot did with Dark Dawn in the end, except far worse.
Not even using MineCraft as a base? (Do note that I said
a Golden Sun project, and not necessarily this one to be exact.)
But yes, for this, what you say pretty much makes sense because most of the graphics seem to have the most appeal in 2D, I think. (Etc.)
QuoteYou still can enroll and you can access the material without worry about time. Time is just for grading.
Thanks... but... it turns out I need to log in to enroll....
I have a request... :P When you have all your battle mechanics in place and are thinking of which psyngery to insert to test out. May I recommend Agaitos Rising Dragon. There are two rising dragons move, but his is the coolest looking psyngery in the game and one we sadly never got to learn.
...Stick with the basics. Team Isaac is a known quantity - we know how they're supposed to work. When testing spells, that's what should be used. Hold Rising Dragon for when testing gets to the more fancy things.
Suppose jumping and pushing objects would be the most reasonable next step as far as basics go. EDIT POST 666.... Number of the Beast!! :MarsSet: :MarsSet: :MarsSet:
@Field jumping & pushing = By the way, have those been done yet? (I'm thinking most likely, but I just want to be sure.)
Either way, I think Rolina was referring to what's most reasonable for Battle Mechanics...
QuoteEDIT POST 666.... Number of the Beast!!
Muslim's holy number ; Bible's evil number.. -- Which do you pick, holy or evil? (<== Supposed to be rhetorical.)
They havent been shown as off yet. So id assume not yet.. though in my defence, I did say when the battle mechanies were in place in my orignial post.
It's been a long time but in case you missed it, I posted a new video:
Quote from: OpenGoldenSun on 28, October, 2015, 05:30:45 PM
It's been a long time but in case you missed it, I posted a new video:
just awesome!
Good job! Didn't miss it, but that's only because Kyle mentioned it in the cbox last week... (If he hadn't, I wouldn't have seen it until now, most likely(?)) But anyway, keep it going...
Sounds like someone should be subscribing! :happy:
Oh... It turns out I haven't subscribed yet...... *done* Hm... I don't always check my youtube for updates... so I've no idea how well it will keep me up to date or not if I'm not checking much...
Quote from: Fox on 23, April, 2015, 07:16:57 PM
@Field jumping & pushing = By the way, have those been done yet? (I'm thinking most likely, but I just want to be sure.)
Either way, I think Rolina was referring to what's most reasonable for Battle Mechanics...
QuoteEDIT POST 666.... Number of the Beast!!
Muslim's holy number ; Bible's evil number.. -- Which do you pick, holy or evil? (<== Supposed to be rhetorical.)
Aye, I was. Battle mechanics is what I know, you know?
Still, looks like at this point he's working on what could arguably be the more important part of the game to focus on, since you spend more time in the overworld than in battles. Good idea, I think - once we've got working navigation, maps, tiling, puzzles, etc then we can move on to battle stuff. I look forward to trying out the demo when it's out.
Quote from: OpenGoldenSun on 28, October, 2015, 06:17:40 PM
Sounds like someone should be subscribing! :happy:
Great work, Mr. Opengoldensun!
I think I watched your videos at least 10 times each, :) !
Quote from: Rolina on 28, October, 2015, 06:57:27 PM
Still, looks like at this point he's working on what could arguably be the more important part of the game to focus on, since you spend more time in the overworld than in battles. Good idea, I think - once we've got working navigation, maps, tiling, puzzles, etc then we can move on to battle stuff. I look forward to trying out the demo when it's out.
I agree. The heart of Golden Sun is in the exploration/puzzles and the dialogue, both of which occur in the overworld. The combat, on the other hand, while needed to complete the project, is not particularly nuanced, I think, or especially different from other JRPGs, aside perhaps from Djinni.
Little shout-out to the forums in this one:
Emoticons or Emoji? Either way, nice work!!!
Emotes. Emoji are a brand name iirc, so they refer to something very specific.
@What I was thinking:
Emoji is used for telling stories without using textual characters (And is usually hard to understand(?)) (At least on The Late Late Show with James Corden,) - A bunch of these are actually Unicode characters themselves, but I don't think they display correctly everywhere. (May appear correctly in textbox, but blank when submitted.) ;
Emotes are usually used for emotions/feelings.... but we end up using them for general purposes.. (PCs/objects/etc) ....so that's why I asked.
But in another way... I'm not sure if this is like comparing "cartoon" to "anime".... (Which I think? Is based on location?)
Maybe I could choose a less controversial term and call them "icons"....?
I figure it's more of a "band-aid" vs "bandage". Technically, a bandaid is a brand of bandage. However, Band-Aid makes you think specifically about those adhesive bandages you put on cuts while bandage makes you think of those wrap-around bandages for larger wounds. So while technically both are bandages, and band-aids even have those wrappable kinds, the brand vs the item itself makes you think two different things.
When I think "emoji", I think of that god-awful stuff that's popular now thanks to that one company and phones and stuff. When I think emotes, I think of the simpler types you see on forums and in games.
...Actually...
Dark Dawn uses Emoji
The GBA games use Emotes
That's a good way to put it, IMO. They have a different feel to them, you know?
QuoteIsaac: "Hey! I take offense to that."
You take all the fence you like.
Edit: Just so this post isn't spam: that's pretty cool. Also lol @ Jenna's head as an emote. And also reddit and youtube and twitter emotes.
I've been working on getting some of the puzzle mechanics working properly.
Ahh... I didn't even see the update until now. Again, great work.
Bunp.
Is this thing still a thing?
It is. Follow him on youtube - he's got several more vids than that.
Wow man!! :!:
The new stuff looks good!
I really like how you made this little cutscene.
I really wonder about some things now though:
-How do you record and what resolution?
-What is the internal resolution of the game and do you use filters? (because it really looks like the normal game with smoothing effects)
-How much of the normal engine is already done?
Quote from: Luna_blade on 24, October, 2016, 12:18:57 PM
Wow man!! :!:
The new stuff looks good!
I really like how you made this little cutscene.
I really wonder about some things now though:
-How do you record and what resolution?
-What is the internal resolution of the game and do you use filters? (because it really looks like the normal game with smoothing effects)
-How much of the normal engine is already done?
I use Fraps and record at 1200x800. I then use Handbrake to reduce the file size since Fraps is uncompressed. The internal resolution of the game is the same as the GBA, 240x160 and it uses the HQ4X filter.
What is considered the normal engine? I haven't even begun reworking/remaking the battles or world map.
Quote from: OpenGoldenSun on 24, October, 2016, 12:33:21 PM
I use Fraps and record at 1200x800. I then use Handbrake to reduce the file size since Fraps is uncompressed. The internal resolution of the game is the same as the GBA, 240x160 and it uses the HQ4X filter.
That's pretty nice.
A thing I like to propose, is changeable resolutions, as well as other customization options.
Quote from: OpenGoldenSun
What is considered the normal engine? I haven't even begun reworking/remaking the battles or world map.
There is no general engine I suppose; but what I meant was: Movement, dialogue, basic psynergy, basic battle system, djini's,stats and status systems, a basic overworld.
I know you made the first few things already.
gracias por tu trabajo crack. lo sigo de muy cerca
I'd love to see an update detailing battles. I'd also love to see a demo of adding custom stats and changing formulas.