gbadev.org forum archive

*Further EDIT* Link to most recent release of file: thegamefreak0134.googlepages.com/SmashBrosAdvance.zip (may contain most current issues, not official release)

*EDIT* Name was changed from CPU usage issues. Same thread, but it's become more of a general project questions thing.

Alright, I'll just come out and admit it, too much beating around the bush. A friend of mine and I are working on porting Super Smash Bros. to Gameboy Advance. Obviously this will be a huge project, so we will need all of the support we can get on various issues. The following are numbered, so indicate please which one you are responding to. (BTW, multiple responses on issues are more than welcome. This means by all means please don't not-respont just because you haven't read the whole thread yet.)

First off, don't worry about how we are going to pull off various parts of the game. Being the main logic wroter for the game, I can assure you that we have figured out *how* to include each and every detail to emulate the original game accurately. (right down to the priority and weight things.) We are even going to fake a camera flying around the "stage" by using affine maps and a heck of a lot of scaling. In fact, this is my main concern for this topic.

(1) First and foremost, does enabling affine transformations take away any CPU time? (other than writing to the registers.) If so, how significant is the processor time loss, as opposed to not doing any affine transforms. (note that we will be using 1 affine bg and a large number of affine sprites, but all of them will use the same matrix, as they will all "zoom" at the same rate.)

(2) Second, what is the fastest possible way to do variable ammount division? For our sprites to be positioned right on-screen, we will need to run the origins through a formula taking screen size and camera position into account, and this operation will require (I believe) 2 division operations per sprite, 1 divide for level scaling, and 2 divides for level positioning. Since we will have 4 characters, 5 max items, and around 20 projectiles max to be calculated, this equates to a lot of divide operations. Of course, optimization can be taken into account (like not calculating stuff that's off-screen, for instance) but it still will be very CPU intensive.

What would really help a lot would be this: How many cpu cycles are actually given to code processing each frame, and how many of them are used for an integer divide? (assume that we use s16 variables for positioning, which we prolly will.) This will help because we have to be able to actually process the game at the same time we're doing all of this. Thank god I don't think we need to use sine or cosine at this point...

(3) Another issue that will be a problem is hit detection. This is really a logic question, but it's still worth asking. If I have in memory a "fake sprite" if you will, that represents exactly where on that character's current animation frame a hit will actually strike the character, how do I go about figuring out if a hit strikes? The way it will be set up, hits will be "generated" by certain moves, and these hits will have X and Y positions on the level. I need to be able to process each hit in turn and see whether or not it hit anything, based purely on character/item/projectile positions and "hit maps" in memory. Is anyone familiar with a way to do this? Thanks!

(4) For the levels, we are going to have things go all wonky. The level itself will basically be a tile-mapped image. (for the record, mines will change tiles on the map so as not to take up any sprite projectile room.) However, we want the physics of the level to take place entirely in memory. I would like to know if there is a program that will let me layer images, so I can use tile-maping techniques to design the actual physical representation of the level in 8x8 "tiles".

Basically, anything that doesn't move will go in this map. It will have several "tiles" that represent areas a character can stant on, and every other "tile" will be simply non-passable. That way rather than doing complicated hit detection, we just check if a character is flying toward an applicable tile and if so, bounce accordingly. It's a little crude, but for the GBA I think it will be more than workable.

Platforms in the level will be another story. Since platforms are mobile, I was thinking of doing it this way. Rather than have every character have collision checks for every platform, why not have the platforms do collision checks with the area around them? Then, if a character "lands" on a platform, their regular walking state becomes their "platform-walking state" and they move along with the platform. Of course, I could also not do moving platforms, but that woudn't be any fun, now would it? :-D

This project is still in its very early stages. In a couple of weekswe should have a character walking around (and possibly jumping) on a level, but it will be some time before we actually have a proper "fight" going. As soon as I have anything worthy of being called a "demo" up (be it one of our debud stages of whatever) I'll let y'all know. Thanks again for any help you can offer!

-thegamefreak0134

PS: All of this was typed away from the web and I apologize for any typos or fragments and such...

PPS: This is also going through our school filter. I loke being able to get around it, as it's like the most badd-a** filter that exists.
_________________
What if the hokey-pokey really is what it's all about?

[url=http:/www.darknovagames.com/index.php?action=recruit&clanid=1]Support Zeta on DarkNova![/url]

Last edited by thegamefreak0134 on Sun May 14, 2006 8:39 am; edited 2 times in total

1) No.

2) There are a number of threads here about fast divides.

3) You'll want a tool to associate auxiliary bounding boxes with each frame of graphical animation. I'd recommend at least a box for "body" collision (which can be hit) and "attack" collision (which can hit bodies).

4) I don't know what you mean by having physics "take place in memory", but what you describe is so common that it could be considered the "normal" way of doing BG collision on 2D platforms. As far as platforms, simply reversing the detection doesn't necessarily keep you from having to check every platform against every character. If it's too slow, some kind of sorting may be required.

By "in memory" I simply mean that the on-screen coordinates and the actual fighting/level/collision coordinates will bear no significance to one-another. We intend (and I already have routines for this that work) to have a "camera" flying around the stage, so the coordinates will be relative to the map, not the screen. A drawing routine takes care of actually positioning and scaling stuff properly.

I think I have a partial solution. How do you do an "onion skin" in mappy, with different tilesets for different layers? If I could do this, I could just create a map for different "behaviors" of different areas of the screen, and run the associated routine with that particular tile for collision.
_________________
What if the hokey-pokey really is what it's all about?

[url=http:/www.darknovagames.com/index.php?action=recruit&clanid=1]Support Zeta on DarkNova![/url]

Yeah, that's the right way to do game logic.

I haven't used Mappy in a long time. You might want to read the manual.

Actually I am pretty sure #1 will take away some CPU time. You either have to setup a HDMA per scanline (probably the most efficient) or something else exotic (read intensiv). Since the GBA doesn't have true DMA, the CPU is locked whilst the DMA occurs, you are losing CPU cycles - potentially quite a few CPU cycles while updating the scroll/scale registers.

#2 - Consider a huge-ass fixed point reciprical table and mulitply by it. Failing that, place a fast ARM divide routine is IWRAM. Also, you probably will be able to cashe the divides or create a pattern that will optimize well here.

#3 & #4 - as per Saji. This is the most common way to do this sort of thing.

Good luck.

Miked0801 wrote:

Actually I am pretty sure #1 will take away some CPU time. You either have to setup a HDMA per scanline (probably the most efficient) or something else exotic (read intensiv). Since the GBA doesn't have true DMA, the CPU is locked whilst the DMA occurs, you are losing CPU cycles - potentially quite a few CPU cycles while updating the scroll/scale registers.

I think he was only talking about using the basic affine features, which require only up to 1 update per VBlank, and not about doing raster effects.

Dan.

Well if that's the case - then yeah, no true cost :P

How do you plan to keep Nintendo from shutting down your project due to copyright issues?

And how do you plan to implement "tap"/"smash" moves, which depend on the rate of change of position of the analog stick, on a digital pad?
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

tepples wrote:

How do you plan to keep Nintendo from shutting down your project due to copyright issues?

And how do you plan to implement "tap"/"smash" moves, which depend on the rate of change of position of the analog stick, on a digital pad?

If he's not planning to sell this I have doubts Nintendo will bother to do anything, and if they do it'd more likely be just to scare the project away.

I guess he can't really implement smash moves, playing the N64 SSB isnt too bad (using a keyboard), although it does ruin some of the gameplay

Wishful thinking re: Nintendo.

(Then again, wishful thinking re: the whole port idea, if the number of failed amateur projects is any indication.)

Lessee...

First off, I am his friend that is working with him on this project.

Second, If Nintendo wants to shut down SSBA, fine. Just because the characters are copyrighted doesn't mean that we can't make characters that do just about the exact same thing. Since the scenario is copyrighted, we'll just have to come up with another one. (SSB had "Action Figures," and SSBM had "Trophies." We just need another one.

Third, my friend has thought of three different modes, selectable for every person playing, (if we get a linked version working,) to allow for different playing modes. BTW, tilt and tap are referring to the state of a joystick.

Mode A - Hold is tilt, tap is double hit. (Like the Kirby advance games.) To perform a smash attack, double hit and release (don't hold) and press the desired attack button. To dash, double hit and hold.

Mode B - Hold is tilt, tap is hit and release. To perform a smash attack, hit and release and press the desired attack button. To dash, double hit and hold.

Mode C - Every hit is considered a tap. (Kinda how it plays on emulators.) To perform a tilt move, jump and hold desired direction, and when you come back down, press desired attack. Smash attacks and dashing should be kinda self-explanitory.

Angular motion is going to be a bit of a problem[, so lets see if I can come up with an idea on the spot]. Here's an example, how about Fox's FireFox move (Up + B)? there is a timer for each direction, and it adjusts it's angle according to how much time was on each button, and if someone just so happens to get lucky and get an equal amount of up and down, the one pressed last, (if any are pressed, if not, it would go straight up,) would take (lets think of a nice word...) precedence over the others.

Oh yeah, even if we don't finish it, (I think we have a good chance of getting a working battle up eventually,) we've already learned ALOT of stuff for the GBA.

1. Tile modes. (I'm suprised to say that I didn't use any one particular guide for this, I had to use a few together.)
2. Scaling BGs and sprites. (Yay, matrix math.)

We also plan on learning timing, states, animation, prioritys of sprites and BGs, menus, and the affine matrix.

Got to go, bye!

1) No clue

2) Make a 2D array of all of the numbers devided during the loading screen so that in-game you just plug the numbers in for immediate response, eg: divide[dividend][devisor] .

3) Just use the grid-snap you discussed with me that you're using for movement. have all hits layered onto the grid(or a 2nd grid) and as all characters are drawn, check the grid.

4) Additionally, you should work out how characters can jump through an area from below, but must hold down to fall back through.

X) I am doing some studies on multiboot crap & linking, and I will share my finds with you after I am done ^_^ somehow i think there will be too much data in your game to work for multiboot, but all the same....

BTW all I am another friend of his who is also (sort of) helping him make SSBA.

- Nat S. Orion

Quote:

BTW all I am another friend of his who is also (sort of) helping him make SSBA.

Just a hunch, but are you (for lack of willingness to post a real name) the "friend" who has been keeping in touch via e-mail?

For the multiboot issues, we have a solution that just might work. Because we intend to make several versions of the game, each with different character sets, multiboot games will send the character info (sprites, states, data, etc.) to the other carts. Since only 4 characters max are required, I think we can get it to fit by using reduced frames for character anims. (providing of course that it doesn't affect the gameplay.)

I'm not even going into multiboot yet, however, because I am having a serious issue with my function to display stuff. If I use signed or unsigned variables, I cannot create a variable with only 9 bits. (I have to use 16.) Normally this isn't a problem. However, I suspect that when I try to use a negative value, it ends up changing the other attributes in the OAM for that sprite, thus screwing the sprite's location over entirely. Is there a quick easy way to take <number> and if less than 0, adjust to fit in a 9-bit variable? Without this, I'm getting sprites to disappear randomly or go flying in random directions. Not cool.

If that doesn't work (and it might not) I may post code to have it reviewed. It works fine on the calc, but I can't get it to work on the GBA for some reason. Any help would be great.

Thanks!

-thegamefreak0134
_________________
What if the hokey-pokey really is what it's all about?

[url=http:/www.darknovagames.com/index.php?action=recruit&clanid=1]Support Zeta on DarkNova![/url]

thegamefreak0134 wrote:

If I use signed or unsigned variables, I cannot create a variable with only 9 bits. (I have to use 16.) Normally this isn't a problem. However, I suspect that when I try to use a negative value, it ends up changing the other attributes in the OAM for that sprite, thus screwing the sprite's location over entirely. Is there a quick easy way to take <number> and if less than 0, adjust to fit in a 9-bit variable?

Yes, and it's in the GBA beginners' FAQ.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

Although it's hiding under a slightly different description than the way you worded the question. I stared at the faq for 5 minutes before finding what tepples was talking about.

If I'm not mistaken, he's referring to this:

Code:

OAM[n].attr0 = other_attr0_attributes | (y_coordinate & 0x00FF);
OAM[n].attr1 = other_attr1_attributes | (x_coordinate & 0x01FF);

under the question Why do my sprites become corrupt when I move them off the top or the left side of the screen?

Ahh... OK, that makes a lot of sense. Thanks!

Unfortunately, I don't think that's the problem either. Oddly enough, this is happening before they ever get to the edge. (although I'm using double size sprites and scaling, now that I mention it...) I'll look into this as a fix. Thanks a bunch! Without this camera thing working... well, I just don't think the game would play as well.

I feel really stupid for missing a beginners question... I thought I was past this whole newbie thing already.

-thegamefreak0134
_________________
What if the hokey-pokey really is what it's all about?

[url=http:/www.darknovagames.com/index.php?action=recruit&clanid=1]Support Zeta on DarkNova![/url]

OMG! I got it to work! w00t!

Turns out the problem wasn't that at all. I was working on the camera function, and had it going in 2 different modes, so it sould scale to either 240 or 160, depending on character position. The 240 positopn had some serious math errors, and now that it's all worked out the function is a complete and total success. Folks, we have a camera on GBA.

The original problem was occuring only because my math was wrong. I thought is was wierd, because the function is supposed to keep all characters on-screen at all times. (therefore, the values can't ever be negative.) Now it works great.

Next step: Physics. Wheee fun!

-thegamefreak0134

PS: I would post a demo, but it's not exactly doing much except moving sprites, so it's really not worth it.
_________________
What if the hokey-pokey really is what it's all about?

[url=http:/www.darknovagames.com/index.php?action=recruit&clanid=1]Support Zeta on DarkNova![/url]

just a random thing to keep in mind. assuming your code permits this, do this...
leftbound = min(p1x,p2x,p3x,p4x)
rightbound = max(p1x,p2x,p3x,p4x)
topbound = min(p1y,p2y,p3y,p4y)
bottombound = max(p1y,p2y,p3y,p4y)
And that should be all you need to do to make it support 3+ players instead of just two.

- Natso <your friend, Zach ;) )

Nice. Unfortunately, my calc version already uses 4 players using the exact same interface. It should be extremely easy to make the change in my routine too, since I basically used the same logic in both versions.

OK. Problem. (prolly a quicky too.) I can't figure out how to include the standard C++ library files. (or any other such "standard" stuff.) As a result, the standard min() and max() functions are unavailable to me. I can of course emulate the logic via code, it's not that hard, but I'm concerned about speed. What's the fastest non-asm way of accomplishing this operation?
_________________
What if the hokey-pokey really is what it's all about?

[url=http:/www.darknovagames.com/index.php?action=recruit&clanid=1]Support Zeta on DarkNova![/url]

The standard library doesn't have min() or max() for more than two arguments anyway. Just write it simply.

a/b/c/d being the numbers...

//calc max
x=a;if(b>x)x=b;if(c>x)x=c;if(d>x)x=d;

//calc min
x=a;if(b<x)x=b;if(c<x)x=c;if(d<x)x=d;

not too hard...

<looking through your code i noticed the high similarities, and also that you attempted and commented out your min/max attempts ^_^ replace a,b,c and d in my above code with the Xs & Ys of your characters and I think this may be as fast as the calculating can get...>

Awesome. I was considering that, but just wanted to know speed wise. Thanks.

I'm working on a text system (I can handle this one) to go about telling me what all of my various numbers are, and then I'll go into getting a character to be in various "states" and such. I'll begin with kirby and just do a simple walking state. I might also work on the code (and animations) for the "magnifying glass of doom" (offscreen) and the death animations, all of which can be done without doing too much extra. When I have problems, I'll ask for help.

Y'all have been a great help so far. Thanks!

-thegamefreak0134
_________________
What if the hokey-pokey really is what it's all about?

[url=http:/www.darknovagames.com/index.php?action=recruit&clanid=1]Support Zeta on DarkNova![/url]

If you still have my old code from Mokou that I gave you then look through it, I included some very easy to use Text display stuff... you may have to work on getting the letters right but If the version I sent you had a working high-score chart then there are some simple functions that you can easily edit to display numeric values in base 10 on-screen...

EDIT: check your PMs ;)
_________________
I'm a bomb technitian. If you see me running, try to keep up ;)

OK, now that I've gotten into all of this, I have some not-necissarily-urgent questions. I am going to have about 100 (at least) different frames of animation for each character, to be thrown about and used in their various states. Since I am going for simplicity and not size at this point, I am going to use 32x32 or 64x64 (character dependant) sprites for every animation frame.

I will of course need to easily be able to access frame number X for each character. Can I do it this way:

Code:

memcpy( (u16 *)<tilemem>, &KirbyFrames*(framenumber * sizeof(KirbyFrames)), sizeof(KirbyFrames) );

If I can do it this way, is there a special way I need to format my sprite data so there are no bytes inbetween the values?

Also, is there a program that will let me take mass number of frames (all PCX files) and export every one in a text file with the proper formatting?

Thanks!

-thegamefreak0134
_________________
What if the hokey-pokey really is what it's all about?

[url=http:/www.darknovagames.com/index.php?action=recruit&clanid=1]Support Zeta on DarkNova![/url]

assuming there is only 1 palette for each character, and all the sprites of each character are the same size, send me a single file(any format, but bmp will let me get the best output)with all of the frames vertically lined up, and I will convert it(using corel photopaint) to a pcx file(corel can create an adaptive palette so it will be optimized for the frames and look as good as possible. then just using pcx2spr will create a large array(sort of) of frames and a single palette.
On the other hand if you have an alternative way to do the same thing, do so cause you'll understand how to handle the output better.
_________________
I'm a bomb technitian. If you see me running, try to keep up ;)

I actually figured it out. My version did not work, because apparently C++ stores pointers on a stack, and then accesses the pointer rather than the data directly using memcpy. Assuming that all of my pointers are defined in order of frames, I simply increase by one to go to the next frame. It works!

It's funny though. I tried it with my kirby sprites (walking, directly ripped) but forgot to include the delay... and well.. kirby is running really fast. Oops...

-thegamefreak0134
_________________
What if the hokey-pokey really is what it's all about?

[url=http:/www.darknovagames.com/index.php?action=recruit&clanid=1]Support Zeta on DarkNova![/url]

At the risk of making a big deal out of something you already know:

I was looking at your code from the download on the main page, and you're putting image data in .h files. I know you're just doing test and proof-of-concept builds now, but it's really a good idea to avoid doing....

It's almost always worth taking the time NOW to put them into separate source files, then setting up a makefile to manage the builds.

(if you've already thought through this, and have a reason for it, then I apologize for the oft-repeated rant)

I've actually never considered doing that, and still yet don't see any benefits at this point. We're going for ease of coding, and only optimizing for speed. Besides, with the way the graphics engine is going to be running, I need to be able to have exact (like, C++ exact) controll over where the pointers are going to be in memory. Since I don't see how it will affect either speed or size of the final output (and since size will never need to be a concern, probably) I'll stick to header files.

I'm working on a function to design (not implement quite yet) the fighting states for the characters. Since it incorporates both states and frames into the program, I can use it to basically design the entire character. The only thing it doesn't do is handle hits, which will be another story all together.

Actually implementing states is going to be a royal pain ini the rear (especially because I think they will be a significant slowdown) so expect some headaches before we get the next demo out.

By the time you see the next demo, we intend to have kirby successfully walking around on the platform and (if he falls) dying with cute animations. Not messing with mario at this point.

-thegamefreak0134

PS: Don't tell Nintendo about any of this. I've heard too many horror stories of smash bros. projects getting fined. (last I heard, the DS project guy was fined $150,000) Not happening here, if it can be helped...
_________________
What if the hokey-pokey really is what it's all about?

[url=http:/www.darknovagames.com/index.php?action=recruit&clanid=1]Support Zeta on DarkNova![/url]

Quote:

PS: Don't tell Nintendo about any of this. I've heard too many horror stories of smash bros. projects getting fined. (last I heard, the DS project guy was fined $150,000) Not happening here, if it can be helped...

Are you serious? Can you post a link to this story - I would like to read that.

I would, but it appears that their boards are down.

dual-soft was doing it. It was looking to be pretty nice, but nintendo fined the head guy and they canceled the project to not have to pay the fine. They had screenshots and everything! Stupid Nindendo monopoly...

-thegamefreak0134
_________________
What if the hokey-pokey really is what it's all about?

[url=http:/www.darknovagames.com/index.php?action=recruit&clanid=1]Support Zeta on DarkNova![/url]

Replace Nintendo characters with original characters, and what would Nintendo be able to take you to court about?
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

thegamefreak0134 wrote:

Stupid Nindendo monopoly...

Uh, Nintendo created the characters so they have intellectual property rights over them. It's just like if you created an original game with original characters, and made money from it, you wouldn't want other people ripping them off and reducing your income for your hard work.
_________________
http://chishm.drunkencoders.com
http://dldi.drunkencoders.com

thegamefreak0134 wrote:

PS: Don't tell Nintendo about any of this.

Homebrewers aside, who else do you think lurks on this board?

thegamefreak0134 wrote:

Stupid Nindendo monopoly...

I'd like to hear your definition of monopoly. I don't consider Nintendo's intellectual property a commodity or a service.

-Brendan

Using the word "intellectual property" muddles the issue. In this case, the proper term is "copyright".

Copyrights are government-granted monopolies.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

True. But in this case, all but the most die-hard anti-IP people and "information wants to be free" fans would agree that this is the proper use for copyright law, as opposed to many of the abuses of copyright that we see nowadays.

Back to the game:

Quote:

We're going for ease of coding, and only optimizing for speed. Besides, with the way the graphics engine is going to be running, I need to be able to have exact (like, C++ exact) controll over where the pointers are going to be in memory.

Just curious, what does using headers files offer as far as inreased control?

Also, in my experience, in the long run, coding is much easier with the graphics separated out. But hey, it's up to you :)

For the record:

(1) We do NOT intend to leave out any original characters. At all. It wouldn't be smash bros without them, of course.

(2) Since the engine will be our own design and simply mimick the Nintendo version, and since we are going to be using our own "concept", there isn't anything to worry about there.

(3) We're not selling it. I believe the mentioned project was going to sell the darn thing. If I can figure out how to get a paypal account we may accept donations, but that will be the extent of it.

</rambling>

On to the task at hand, then.

I personally like using header files cause they give me a nice easy to use pointer to my data, plus I don't have to arrange my compiling to include new ones. It's just simpler to me.

I have a question:

In order for my states to really work, for each state there will be a (small) function that needs to be run: one every frame of the state, and one at the end of the state. Is there a way I can tell my code to say, "run the function at this pointer, the return"? It would avoid me having to have a giant check against every function for a value, or anything like that.

I ask because I know there should be a way, but don't know how to do said thing in C.

Thanks!

-thegamefreak0134
_________________
What if the hokey-pokey really is what it's all about?

[url=http:/www.darknovagames.com/index.php?action=recruit&clanid=1]Support Zeta on DarkNova![/url]

thegamefreak0134 wrote:

I personally like using header files cause they give me a nice easy to use pointer to my data, plus I don't have to arrange my compiling to include new ones. It's just simpler to me.

You might be interested in this thread.

Quote:

I have a question:

In order for my states to really work, for each state there will be a (small) function that needs to be run: one every frame of the state, and one at the end of the state. Is there a way I can tell my code to say, "run the function at this pointer, the return"? It would avoid me having to have a giant check against every function for a value, or anything like that.

Sounds like you are talking about function pointers. Each state can have a beginStateFunc func pointer, and an endStateFunc func pointer. When you start the state, invoke the beginStateFunc using the pointer; and invoke endStateFunc using the pointer at the end. Or you can go C++ and make each state an object
_________________
DSLua - a scripting language for your DS!

thegamefreak0134 wrote:

We do NOT intend to leave out any original characters.

I would recommend not posting any screenshots until it's done then. Or at least use alternate graphics in screenshots, and don't mention any connection to Smash Bros. on your site.

Quote:

I personally like using header files cause they give me a nice easy to use pointer to my data, plus I don't have to arrange my compiling to include new ones.

But if the data is in the header, you can only access it from one .c file, because including it in more than one will get multiple definitions.

Quote:

In order for my states to really work, for each state there will be a (small) function that needs to be run: one every frame of the state, and one at the end of the state.

Yeah, function pointers. Make a table of them, with one entry for each state. Something like this:

Code:

enum
{
STATE_JUMP.
STATE_FALCON_PUNCH,

STATE_NUM,
};

typedef void (*STATE_FUNCTION)(void);

typedef struct
{
STATE_FUNCTION init;
STATE_FUNCTION update;
STATE_FUNCTION exit;
} STATE_ENTRY;

const STATE_ENTRY stateTable[STATE_NUM] =
{
{ JumpInit, JumpUpdate, JumpExit }, // STATE_JUMP
{ FalconPunchInit, FalconPunchUpdate, FalconPunchExit }, // STATE_FALCON_PUNCH
};

And then if you want to make it even easier, make a macro to fill out the table entries for you:

Code:

#define DEFINE_STATE_ENTRY(name) \
{ name##Init, name##Update, name##Exit }

const STATE_ENTRY stateTable[STATE_NUM] =
{
DEFINE_STATE_ENTRY(Jump), // STATE_JUMP
DEFINE_STATE_ENTRY(FalconPunch), // STATE_FALCON_PUNCH
};

Absolutely no difference, but saves some typing :)
_________________
___________
The best optimization is to do nothing at all.
Therefore a fully optimized program doesn't exist.
-Deku

thegamefreak0134 wrote:

For the record:

(1) We do NOT intend to leave out any original characters. At all. It wouldn't be smash bros without them, of course.

No piracy talk on gbadev.org please. You are making what is essentially an update to the NES pirate original game Kart Fighter.

Quote:

We're not selling it.

Neither are the pirates of Pocket Heaven.

If you want help from forum.gbadev.org members on developing the engine, then develop two versions in parallel: one with Grimm/Andersen/Collodi/etc fairy tale characters from the public domain and one with Nintendo characters. Discuss implementation issues involving the fairy tale character version on forum.gbadev.org, and discuss reskinning the fairy tale characters with Nintendo sprites on a ROM hacking board.

It shouldn't be too hard to find a fairy tale character counterpart for each Nintendo character. For instance, turn Fox McCloud into the Big Bad Wolf, etc.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

I repeat, we are going to inculde toe original characters. End of story. If necessary, I will actually secure the rights to use them in my game. I'm willing to pay, simply because of how cool of a project this is. I'm just not going to dish out any money at this point untill we at least have something playable, because it's not really worth it if we don't. No, we don't intend to sell it, but we still want it to be legal, copyright wise. I'll do whatever it takes. OK?

I like your thoughts on function pointers, but I need something more simple, at least until I get the engine more finalized. I need to have an array (a regular old 1 dim C array) with pointers, and then need to be able to say call function:

StateFrame[17]()

Or something to that effect. I need them to be this way because the functions will not necessarily line up with either the states or the frames, and thus need to be separated from the state and frame structs.

Basically what I need is, how do I call a function by using a pointer rather than a function name? If I know this, I can simply make an array of pointers and thats that.

-thegamefreak0134
_________________
What if the hokey-pokey really is what it's all about?

[url=http:/www.darknovagames.com/index.php?action=recruit&clanid=1]Support Zeta on DarkNova![/url]

For my example you would call them like

Code:

stateTable[5].init();

You could also add a frame parameter to the update function pointer type, and then do whatever frame-specific checks inside the function itself. Probably would keep the higher level state machine less cluttered.

Also, it doesn't bother me that you want to use Nintendo's characters, I just don't want to see a fun project get shut down because of over-publicizing it (like Chrono Trigger Resurrection did). Since finishing such a project is a pretty rare feat, you may as well not worry about the legal problems until you get there, and just try to stay under the radar until then :)
_________________
___________
The best optimization is to do nothing at all.
Therefore a fully optimized program doesn't exist.
-Deku

thegamefreak0134 wrote:

I'm just not going to dish out any money at this point untill we at least have something playable, because it's not really worth it if we don't.

-thegamefreak0134

I don't think the amount of money you're sitting on is an issue - nintendo may not care.

"StateFrame[17]() "

in that case couldn't you just have

"updateframe(17)" or something to that effect with appropriate arguments? I'm afraid I don't know much on this end of C++ programming so my suggestion may already be obsolete...
_________________
I'm a bomb technitian. If you see me running, try to keep up ;)

thegamefreak0134 wrote:

Basically what I need is, how do I call a function by using a pointer rather than a function name?

*that* is what a function pointer is... :) You initialize your array with pointers to your functions, and you can call it:

Code:

void state1( void )
{
printf( "State1\n" );
}

void state2( void )
{
printf( "State2\n" );
}

void (*stateFuncArray[])(void) = {
&state1,
&state2
};

int main()
{
printf( "Start program\n" );
stateFuncArray[1]();
stateFuncArray[0]();
printf( "Finish program\n" );
return 0;
}

_________________
DSLua - a scripting language for your DS!

thegamefreak0134 wrote:

I repeat, we are going to inculde toe original characters. End of story. If necessary, I will actually secure the rights to use them in my game. I'm willing to pay, simply because of how cool of a project this is.

I'm afraid you probably don't have enough money to buy 51 percent of Nintendo stock, even if 51 percent of Nintendo stock is for sale.

Quote:

I'm just not going to dish out any money at this point untill we at least have something playable, because it's not really worth it if we don't.

You can "get it playable" with fairy tale characters. What's so hard about replacing Kinopio with Pinocchio during development and then skinning in a franchise once you license it?

Quote:

Basically what I need is, how do I call a function by using a pointer rather than a function name?

Like this:

Code:

typedef int (*main_function_t)(int, char **);

int some_main(int argc, char **argv) {
/* ... */
}

const main_function_t tests[] = {
some_main,
another_main
};

int main(int argc, char **argv) {
int result;

result = tests[0](argc, argv);
if(result) return result;
result = tests[1](argc, argv);
return result;
}

_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

tepples wrote:

I'm afraid you probably don't have enough money to buy 51 percent of Nintendo stock, even if 51 percent of Nintendo stock is for sale.

A hefty royalty per download might work as well... then again, I doubt it. Liscensing franchise Nintendo characters is not easy. Second party companies completely held (100%) by Nintendo have to jump through big flaming hoops to touch them.

You will not be able to make a non-commercial (free) release without upsetting people. A lawyer will contact you as soon as somebody at legal or corporate feels threatened by your project. I advise against doing anything that might make people fussy. I advise you follow tepples' and DekuTree64's advice.

When you finish your project, you'll probably want to contact HAL. Although, if this is a GBA project, I doubt it will see a commercial release. If it's a DS project, then good luck with the big flaming hoops.

-Brendan

This is a GBA project. I do not think nintendo will be "threatened" by anything.

Here's what I'll do for now. Assume for this magical moment that I am going to use original characters. However, miraculously their physics, moveset, and graphics will be extremely similar to those of the original games. (We intend to end up doing our own artwork, so no copyright issues there. ) Here is the list of character "similarities" :

Wolf - Fox
Ball Kid - Kirby
Red - Samus
Speed - C. Falcon
Boy Wonder - Ness
Bob - Mario
Larry - Luigi
Rat-face - Pikachu (sorry fans!)
Fluff-ball - Jigglypuff
Chimp - DK
Dino - Yoshi
Sir. LongSword - Link

Note that this was all typed quickly, and my creativeness was horrid. I don't think any of these names are taken by nintendo, so for forum purposes I will use them, and if they do start shaking sticks at me you can count this forum out of the hassles. Deal?

Now, back to business. I like waruwaru's idea, mainly because I understand it best. I like all of the struct ideas, but for simplicity purposes I don't need it yet.

I'm actually designing a program that I will use to design the states, so I need it all separate for now so I can debug it.

Thanks for all the help. Seriously, from now on no more real names.

-thegamefreak0134
_________________
What if the hokey-pokey really is what it's all about?

[url=http:/www.darknovagames.com/index.php?action=recruit&clanid=1]Support Zeta on DarkNova![/url]

Errrr, right after I read this thread, I found this article...
_________________
DSLua - a scripting language for your DS!

I'm giving you my thoughts because I want to see your project do well. Do what you will.
Google: Zelda Online
It's now called Graal Online.

-Brendan

A major breakthrough has occured. Ball Kid took his first (non-speedy) steps this weekend in the new states system. The function array thing worked beautifully, and I have many uses for it already. I can develop states now, but I need something quick.

I want to use mappy to design my collision maps. As such, I can only use one tileset at a time, but can have multiple layers at once. Can someone give me a small program that can take an array of numbers in an array, subtract a given number from each element in the array, and output the updated array in a new file? It would work fine to have the array as an include file with the same name each time. I would, but I have no knowledge of file-output in C++ and simply asking is much easier. Thanks!

Once I have a way to design collision maps, we should very soon have a fully/operating character. Thanks for all the help so far!

-thegamefreak0134
_________________
What if the hokey-pokey really is what it's all about?

[url=http:/www.darknovagames.com/index.php?action=recruit&clanid=1]Support Zeta on DarkNova![/url]

The easiest way to make a collision map is to use your normal map and look up each tile in a collision look-up table. For instance, tile 123 is always solid, tile 234 is always solid-on-top, tile 345 is empty, etc.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

sgeos wrote:

I'm giving you my thoughts because I want to see your project do well. Do what you will.
Google: Zelda Online
It's now called Graal Online.

-Brendan

I doubt this project will get that big for Nintendo to think it a threat.

Dan2552 wrote:

I doubt this project will get that big for Nintendo to think it a threat.

I doubt this project will not get that big if it is finished. It is a team project creating a game that will be very fun to play and is the sort of game people wish was available on the gameboy.

Quote:

The easiest way to make a collision map is to use your normal map and look up each tile in a collision look-up table. For instance, tile 123 is always solid, tile 234 is always solid-on-top, tile 345 is empty, etc.

I would do this, but due to the nature of the game it will not work this way. We will have some map tiles that do different things depending both on circumstance and area onscreen, and as such their visual representation will not always reflect their behavior.
_________________
What if the hokey-pokey really is what it's all about?

[url=http:/www.darknovagames.com/index.php?action=recruit&clanid=1]Support Zeta on DarkNova![/url]

Quote:

Can someone give me a small program that can take an array of numbers in an array, subtract a given number from each element in the array, and output the updated array in a new file? It would work fine to have the array as an include file with the same name each time. I would, but I have no knowledge of file-output in C++ and simply asking is much easier. Thanks!

What format is the original array in? If it's in a text file, or a C source file, send it my way. And let me know specifically what needs to happen to the array.

But if you do, you're getting a perl script in return.

Quote:

I have no knowledge of file-output in C++ and simply asking is much easier.

man system. A *nix of cygwin dev environment might be needed to do really useful things with system... what am I talking about?

This is more useful:
man fopen
man fwrite
man fread
man fclose

-Brendan

File output is very very easy with c++. Check out iostream.

Your options:

iostream

fopen, fwrite & friends

system

write a custom utility, call it with system

-Brendan

OMG! We have collision!

I bit the bullet and designed it the hard way in mappy. The actual implementation was easy enough though. Now what I have to do is design the behavior for the tiles, and since I've never done a collision map before, this is rather difficult.

I have a couple of things going easy enough. I have some basic code for tiles that "push" the character up, down, left, and right. My biggest concern here is corners. I don't know how to write code that quickly and effectively determines what direction the character needs to be "pushed" from a corner for the collision.

Assuming that I can give you the characters current position (before collision check) and the position right before that, can someone point me in the direction of what the behavior for this should look like? BTW, the tiles are all 16x16 tiles. (This actually works out to 8x8 pixels, but don't worry about that.)

As for such other things as slanting stuff, I actually think I have that worked out. My other concern is keeping standing characters "on" their standing areas, but I think if I just set their downward acceleration to the equivelent of say 4 pixels it will work out fine.

My system works like this: The characters state is checked, they are moved to the next frame of the state, and their position is updated based purely on their acceleration and speed values. Then, their collision is checked, they are "pushed" outside of any tiles they need to be pushed out of, and landing and bounce flags are set accordingly, based on tile type. The system works fine right now for everything except corners.

Course, at this point we don't actually have the physics part implemented, we're still using the motion shown in the release demo to test all of this.

I got a lot done for this week on the project, and I'm happy. Give me like one or more two days, and the GUI State Editor I'm working on will be finished as well, meaning the character design process will actually take off properly. Wish me luck!

-thegamefreak0134

PS: Typed excitedly, so sorry for any typos.
_________________
What if the hokey-pokey really is what it's all about?

[url=http:/www.darknovagames.com/index.php?action=recruit&clanid=1]Support Zeta on DarkNova![/url]

As far as collision goes, this is my general advice:

I have not played a lot of Smash Brothers, but IIRC the stages do not have many surfaces. Instead of tiles, I'd use a list of lines to represent the stage.

No matter what your collision map consists of, basic collision code looks something like this:

Code:

// if I don't hit anything
if ( !critter.willHitSomething( nextPos ) )
{
// move
critter.updatePos( nextPos );
}
else
{
// otherwise get stopped
thing = critter.whatIHit( nextPos );
critter.snapTo( thing, nextPos );
}

Quote:

I don't know how to write code that quickly and effectively determines what direction the character needs to be "pushed" from a corner for the collision.

Have you clearly defined the direction the character needs to "pushed" from a corner? If not, then do so. You can't build something if you don't know what you are making. If you know what you are making, the solution is usually obvious.

Do you really need to worry about quick and efficient code at this point? I'm not in a position to say you don't need to, but keep the follow quote in mind:

Donald Knuth wrote:

We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil.

The first step is to write something that meets specification. You can always rewrite it later if you have a stable interface.

Good luck!
-Brendan

Quote:

A) Separate the display from the collision map.
B) Have the engine blindly run the collision map.
C) Have the same person be responsible for maintaining the collision map and the display.
D) Test, test, test.

I'm already doing that. I'm basically coding the main engine of the game myself. The_Perfection is helping me with all of the more specific register info and will be doing the bulk of the graphics, and Natso is helping tremendoussly with multiplayer stuff.

Quote:

Instead of tiles, I'd use a list of lines to represent the stage.

I would, but tiles are easier for the particular project. I cant put the logic together on how to do a non-tiled collision map anyway. Thisworks for now, so I'm running with it.

Quote:

Have you clearly defined the direction the character needs to "pushed" from a corner? If not, then do so. You can't build something if you don't know what you are making. If you know what you are making, the solution is usually obvious.

Well, there are 4 different types of basic corners. Other than that, no. Determining where they go isn't the problem as determining what edge they strike. If they come in from the top, they need to be aligned there, but likewise if they come in from the side they need to be aligned there instead. However, I don't think I will be able to afford going one pixel at a time because some characters (depending mainly on damage) will have the ability to fly really fast.
_________________
What if the hokey-pokey really is what it's all about?

[url=http:/www.darknovagames.com/index.php?action=recruit&clanid=1]Support Zeta on DarkNova![/url]

Congrats on the collision!
Also, good luck on your contests today ;)
_________________
I'm a bomb technitian. If you see me running, try to keep up ;)

Well, two analysis things happened over the weekend. I looked into the original 64 game, and the collision they use for corners there is something to this effect:

If the position before the collision is to the left of the tile, collide left as a wall, otherwise land. (assuming for left edge corners.) You can actually see it re-aligning like this in slow mode, especially if you use an emu with a cruddy PC like me. thus, I'll use this simple logic and be done with it. Of course if you can find a better method that would be nice but it is not necessary.

The other thing I did here was to design a GUI state editor. It works well, and I was able to re-produce the data I am already using in-game using it, so it will become the official state designer for the game.

My next big project is game physics, and this will be a nightmare, let me tell you. I am considering doing it this way:

Every character will have an Xspeed, Yspeed, Xaccel and Yaccel. Every frame, unless otherwise specified by a state function being run, the accel values will be applied to the speed values, and then the character position will be updated based on the speed values. (It will be more accurate in memory than it is displayed on-screen, prolly.)

The trouble I'm having here is how to get the keys to work with the various states. For any flying state, although you cannot pull off any moves, the D+Pad can be used in the 64 version to kindof "slow" your flying to a certain extend. I am unsure of how to actually get this to work. Will this do the trick:

Character Speed = Character Speed + (Character Accel + KeyAccel)

Where accel values can of course be negative.

By doing this, I can just define a starting speed and accel value for each state and then time the states so that the proper positioning is reached by a certain frame. It will be a lot of work, but the system will be faster in the end (and smaller) which is a good thing. This is in my opinion better than mapping out say a pixel offset for every frame of every move.

Thoughts?

-thegamefreak0134

PS: Once I achieve more than just a walking right state and decent collision, I will post a project update.
_________________
What if the hokey-pokey really is what it's all about?

[url=http:/www.darknovagames.com/index.php?action=recruit&clanid=1]Support Zeta on DarkNova![/url]

I like your idea of game physics, simple, yet they will work.

In the game cube version of SB you can jump in mid air sometimes, will this pose a problem to the game physics because if you are moving left on the x axis and then you suddenly jum and start going right on the x will the accel go from negative, then to zero and then to positive, or just go straight to possitive?

thegamefreak0134 wrote:

The trouble I'm having here is how to get the keys to work with the various states.

Design before implementation is a Good Thing. Write exactly what you want to do on paper. Optional, but a good idea: run you design by a bunch of people. Then code it.

There is an article on the net you might find interesting.
Google: "Debug Menu Super Smash Bros Melee"

-Brendan

OK... wierd, a proxy that didn't work before works now... Wow. Patience is a virtue.

Anywho, I saw the article on the debug stuff, and trust me we intend to buy an action replay and test it out. However, I don't believe we will be implementing the "collision bubbles" as they would probably take way too long to process. We're going to do something similar, (possibly behaving the same) just not that method.

As for the physics of jumping, this is how it will work. Every state, on start, can set the Xspeed, Yspeed, and respective accel values. So for jumping, we have it set Xspeed to nothing and Yspeed for the jump, and then have the function realize that it's the first frame of the state and set the Xspeed according to the key pressed. Or we sould simply have the function checking for the jump go to the left or right jump accordingly. (Take mario's Up+B for example.)

Thanks for the advice. I'll make sure to look into this when I design the routines.

-thegamefreak
_________________
What if the hokey-pokey really is what it's all about?

[url=http:/www.darknovagames.com/index.php?action=recruit&clanid=1]Support Zeta on DarkNova![/url]

i haven't read the article, but if it is a collision bubble as i think it is, using a simple distance formula will work fine...
if( sqrt((x2-x1)^2 + (y2-y1)^2) < charsize)
(I think that is it, fixing the squared parts) and just take the difference between the center of each character and the exact position of hurt-points(eg punches, bullets, main points in weapons, etc... of course you wouldn't have to do the formula all the time. you could do some checks first:
if( x2>x1-charsize)
if( x2<x1+charsize)
if( y2>y1-charsize)
if( y2<y1+charsize)
if( sqrt((x2-x1)^2 + (y2-y1)^2) < charsize)
All that just to minimize the armount of math the GBA has to do...
no clue how you intend to do collision, but i hope this helps...
_________________
I'm a bomb technitian. If you see me running, try to keep up ;)

General Needs for the moment:

(1) I like the collision bubbles idea. I thought at first that there was no way on earth, but if Natso's statement is correct it might actually be our best bet. Apparently nintendo knows what they are doing. Anywho, I have a Q regarding that.

Q: Is there a quick way to do a square root? Is it possible to use an inline bios call to do it, or is there a fast way in C++? If it needs to be bios, how do I go about passing my info to the right asm registers before-hand? (I have limited asm experience, but only in pure asm, no mixed, and pure isn't an option for this yet.)

(2) He jumps! He jumps! K*rby has taken his first ever jump! I had to extend the accuracy of the collision and the levels to get it all to work right, but nonetheless, he jumps! Next step: proper physics, and a few more actions possibly.

(3) Collision woes:

I have a simple solution to a complicated problem, I think. I want to do collision detection for platforms. Since platforms can be mobile having them build into the tileset is a no-go, so I have another possible solution.

(a) Is character moving down? If no, exit
(b) Is character final x pos within platform? if no, exit (yes, it opens a small hole, but not a significant one.)
(c) Does character intersect platform? If yes, perform collision. If no, exit.

I'm having my issues with C. Assume for a moment that the platform is a line segment runnning from point A to point B. Assume that the character starting point is at C and final point is at D. How do I find out in software if AB intersects CD? If I can figure out this, the rest should be pretty easy.

I assume that to actually do the collision I would figure the slope from point A to B, figure the x pos relative to A, and multiply it by slope to give distance. (Player1.x = Xdifference * (Player1.x - A) / ydifference) All in all, 1 divide per character, (and item and projectile, etc.) not too shabby.

I get the feeling these are common issues, but they're all new to me. I've been in the calculator BASIC world for way too long. Being able to do this at all is pretty nice compared to that.

Thanks in advance* for any help you can offer. The physics engine is obviously going great. I'm working on a way to implement gravity into the mix, so I don't have to do it per-state. Once I get that down, I may have a fully functioning physics engine (and a simple one at that). Expect major progress to be taken on this. Once we have a fully working character and a hit detection system going, in my opinion that makes a playable game. However, as you all know, we can't really live up to the name Smash Bros with such limiting options.

For now though, I'm going to release what we have so far as an update to the project. Take a look atht ehofficial readme in there, as it has some various usefull info scattered about. Note also that this is my personal first project to actually have a history. yay!

Thanks again for all the help.

-thegamefreak0134

*PS: Do you think we should start saying "Thanks in DS"?
_________________
What if the hokey-pokey really is what it's all about?

[url=http:/www.darknovagames.com/index.php?action=recruit&clanid=1]Support Zeta on DarkNova![/url]

thegamefreak0134 wrote:

(c) Does character intersect platform? If yes, perform collision. If no, exit.

I'm having my issues with C. Assume for a moment that the platform is a line segment runnning from point A to point B. Assume that the character starting point is at C and final point is at D. How do I find out in software if AB intersects CD?

Google is your friend
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

Method described here. Basically there is a method to calculate the area of a 3 point polygon ABC using the 2d cross product. This method also tells you whether C is clockwise/anticlockwise from AB. This method is used to do line/line collisions using 4 multiplies [if memory is right].

thegamefreak0134 wrote:

Q: Is there a quick way to do a square root? Is it possible to use an inline bios call to do it, or is there a fast way in C++? If it needs to be bios, how do I go about passing my info to the right asm registers before-hand? (I have limited asm experience, but only in pure asm, no mixed, and pure isn't an option for this yet.)

I'm assuming you're referring to this test from above:

if( sqrt((x2-x1)^2 + (y2-y1)^2) < charsize)

If so, you don't need the square root. Just square both sides of the equation:

if( ((x2-x1)^2 + (y2-y1)^2) < charsize^2)

Same result, but much faster to execute.

As edwdig suggested, not doing square root is the fastest. Beware of overflow, especially if you are using fixed point numbers. (Sounds stupid, but I've actually run into that problem.)

In response to "I'm having trouble with (c)", I find that drawing pictures of what I want to do helps me solve problems.

-Brendan

Well I feel stupid. Of course I don't have to do a square root, and since I use u32 for calculation anyway (more accuracy and apparently it's supposed to be faster on a processer level) I don't have to worry about overflow. Cool.

I want to draw a graph, I really do, (and in fact I will.) Take a look below.

http://img506.imageshack.us/img506/7279/graph1im.png

(proxy not letting me do the image tag) Anywho, I have a platform from A to B and a character (in one frame) traveling from point C to point D. Tell me (with math) if lines AB and CD intersect. All you have is the X and Y coordinates of the points, and mad coding skills.

I would naturally assume it's really something simple, but it's not exactly clicking for me. If you could tell me (assuming that A is at the origin) the X position on the line that the intersection occurs (if it occurs at all) that would help a bunch, as I could do the rest from there. Unfortunately, my math teacher (who doesn't know about the real purpose of this all) istructed me to use a graphing calculator. Gee, what a help he was.

-thegamefreak
_________________
What if the hokey-pokey really is what it's all about?

[url=http:/www.darknovagames.com/index.php?action=recruit&clanid=1]Support Zeta on DarkNova![/url]

keldon wrote:

Method described here. Basically there is a method to calculate the area of a 3 point polygon ABC using the 2d cross product. This method also tells you whether C is clockwise/anticlockwise from AB. This method is used to do line/line collisions using 4 multiplies [if memory is right].

Figure out the point at which the lines intersect. If that point is in both line segments, then the lines intersect. You only have to test X or Y (not both) to see if the point intersects. Why? The answer to that question is your home work. =) Reading the other thread will help.

-Brendan

OK, I've released a demo. (no, I haven't figured the platform thing out yet, I'm workin on it.) It showcases the physics engine and states and frames and stuff. (You can walk and jump.) Arrows to walk, A to jump. Yes, it will be changed to up later.

Have fun. No proper gravity yet, but it will be added later.

-thegamefreak0134

PS: The source is included, if you want a good laugh.
_________________
What if the hokey-pokey really is what it's all about?

[url=http:/www.darknovagames.com/index.php?action=recruit&clanid=1]Support Zeta on DarkNova![/url]

Where can I find the latest build? I look through the thread and couldn't find a URL. I can only find the April 9 version....
Thanks

tepples wrote:

thegamefreak0134 wrote:

I repeat, we are going to inculde toe original characters. End of story. If necessary, I will actually secure the rights to use them in my game. I'm willing to pay, simply because of how cool of a project this is.

I'm afraid you probably don't have enough money to buy 51 percent of Nintendo stock, even if 51 percent of Nintendo stock is for sale.

Even then there would need to be 51% of Nintendo Stock Available in _all_ the countries in NA, PAL, EU and whatever the fourth area is. You'd then have to convince Shinguru Miyamoto to let you use his characters, which won't be easy, as he has often stated he wants his success to use new characters (which looking at the problems Disney is having with their copyrights and trademarks expiring, might be a wise thing for Miyamoto to do)

Heck when "Circuit City" bought out Radio Shack in Canada, they had to rebrand everything, because they had bought everything Radio Shack owned in Canada, except for the Trademark rights (in fact one Radio Shack still exists in Canada--it is in Halifax somewhere IIRC)

So unless you are Shiguru Miyamoto's descendant, and even then, you are no likely to be able to pay for Nintendo's rights.

Though, if you could get the play mechanics similar to Smash Brothers, I really don't care what I am playing as, really.

edit: remind me to read the whole post before jumping in with a reply next time.

Clever new names. Once the KRFP is up to par, we may need to do a Kid Radd Vs. whatever you are calling this group.
_________________
[ Main Site | Kid Radd Fan Project | Forums ]

Ok, to make you all happy I tried to figure this out on my own, and this is what I got:

//Point of intersection

Y = ((Y4-Y3)/(X4-X3)) * ((Y2-Y1)/(X2-X1)) + (((X3) * (Y4-Y3))/(X4-X3));
X = (Y)/((Y2-Y1)/(X2-X1))

Where (X,Y) is the point of intersection, (X1,Y1) and (X2,Y2) are the points of the platform line, and (X3,Y3) and (X4,Y4) are the points of character motion being checked. Simple enough, right? :-P

So be happy. I actually went up to a white board and filled it up with random Cra** and logic figuring this all out. Basically, figure out the point-slope equasions for each line, solve for X for one line, plug into the other, solve for Y, use Y to solve for X. The above is all of that in two tidy equasions.

I'm having logic issues however with determining B for the character movement line though. I'm translating all of my points so that (X1,Y1) is at 0,0 so that the slope and all for the platform is easier. However, this still leaves me with a random line location for the character movement line. If they cross either axis, I think the equasion is screwed. (although I haven't officially tested it quite yet.) Will this be a problem?

-thegamefreak0134
_________________
What if the hokey-pokey really is what it's all about?

[url=http:/www.darknovagames.com/index.php?action=recruit&clanid=1]Support Zeta on DarkNova![/url]

thegamefreak0134 wrote:

I'm having logic issues however with determining B for the character movement line though.

I'm not sure if this is the best way of doing things, but you could treat the character as the origin (0, 0) and translate the platforms to that coordinate system. Even if that is not the "correct" way of doing things, after you figure that math out you should be able to operate in any coordinate system you want to.

-Brendan

I don't know if this is part of the logic/problem to be had here, but I should think that figuring the x2 and y2 could be done simply by applying the horizontal and verticle speed to x1 and y1, and if x1 and y1 are at (0,0) then your x2 and y2 are simply the horizontal and verticle speeds...

(just realized that i meant 3 and 4 not 1 and 2 by your logic solving....)

also, about crossing the axis, i think mabey you are talking about losing the negative sign? don't forget you can use s32 for a signed integer... (you probably already knew this but sometimes we humans tend to look past the obvious)
_________________
I'm a bomb technitian. If you see me running, try to keep up ;)

For those of you wondering about it, the demo did indeed go through. (despite wierd return messages.) Check it out. It's replaced the old demo, and is still (incredibly) the top demo on the site.

As for the platform thing, with the way I worked the formula I believe it will actually work itself out properly regardless of axis. Of course, I'm not sure of this at all, but it's worth a shot. I know perfectly well how to use signed integers Natso, I'm already doing so in the source code you have from me. (lol) And as for figuring out the character positions, I will use the physics engine to move the character, and then simply remember the position before that. The engine already collides this way with walls and such, so it will work out fine for platforms. Course, walls don't exactly require the previous coordinate, but that's that's not the point.

-thegamefreak0134

PS: Although the current build has dash support, the demo on-site does not include it. Sorry!
_________________
What if the hokey-pokey really is what it's all about?

[url=http:/www.darknovagames.com/index.php?action=recruit&clanid=1]Support Zeta on DarkNova![/url]

thegamefreak0134 wrote:

I believe it will actually work itself out properly regardless of axis. Of course, I'm not sure of this at all,

This is not a good sign. You should work out your math until you know what your formula is going to do. It will make debugging much easier and you'll probably find a few bugs when doing so. How many times do you read over your code after you write it?

-Brendan

anyone have a compiled version please

Uh... dude1 you might try reading the whole post, especially the more recent ones. The compiled version (a .bin file) is included in the release, which you can download from this site's demo section. Cheers!

Quote:

This is not a good sign.

Uh, yeah I kinda figured.

-thegamefreak0134
_________________
What if the hokey-pokey really is what it's all about?

[url=http:/www.darknovagames.com/index.php?action=recruit&clanid=1]Support Zeta on DarkNova![/url]

thegamefreak0134 wrote:

Uh... dude1 you might try reading the whole post, especially the more recent ones. The compiled version (a .bin file) is included in the release, which you can download from this site's demo section. Cheers!

-thegamefreak0134

You should put the important information in the most obvious place. I looked for this and didn't find it; and considering the topic is about 6 pages long it's no wonder.

Well, I've taken the liberty of creating a site for our group, currently christened "New Folder Productions." There is a story behind the name, but I'll get into that later.

Anywho, here you can find a current project update as well as the latest release of new stuff. Thus, unless I feel the need to do so through gbadev, I will post links to files on this site untill further notice. Note that the site is brand new, and thus we have very little to show. (I put it together, hand-crafted title and all, in about two days.) Thus, the smash bros advance section is all that really works for now.

url: thegamefreak0134.googlepages.com (don't mind the first page, I'm trying to figure out how to make it go away.)

In other news, we have aqquired an Action Replay for the gamecube. This allows us to get into the debug menu for Smash Bros. Melee and tinker aroun d with a lot of different stuff. Best of all, putting the game in develop mode allows us to pull up several different sets of numbers. One of these (and I'm proud) we recognized as a states system for the characters that was apparently running about the same our version was. We are doing things right after all!

There won't be any updates to the game for a while, as we are doing data collection from here. We are trying to figure out what the coordinates can tell us about the speed and acceleration of characters so we can work that into our own physics engine that works right. We will also use the handy frame-by-frame to perfectly time and map out the states for every character. (OK, we'll just do one to start.) The end result will be much more accurate characters, and a much better system. Unfortunately, I think I am going to have to work out a lot of stuff in the physics engine to get it all to work right in our version... Ah well.

-thegamefreak0134
_________________
What if the hokey-pokey really is what it's all about?

[url=http:/www.darknovagames.com/index.php?action=recruit&clanid=1]Support Zeta on DarkNova![/url]

I was doing a exact project like your but the thing was that i didnt know how to code for the gba or the ds, but i made some discoveris that may help you ;)

http://sprites.fireball20xl.com/nintendo/other/ssbm.htm

It has sprites of all characters of the Super Smash Brothers Melee, of the scenarios, and objects and that stuff.

I may help you do some things because i now know some things about coding for gba and ds...

For your project i only ask one thing... please and i repeat, please port the game to DS later on...

(1) Link doesn't work. Bummer, as it would have been useful too. (It's not you, it's our filter.)

(2) We intend to do our own artwork for the game, based mainly on screens from the GC version but hand drawn ourselves so nintendo can't yell at us too severely.

(3) Apparently (for what it's worth) Nintendo is going to make a DS version. There was a very good looking DS Smash Bros. Homebrew going already, and nintendo fined the project coordinator $150,000 for it. Smash Bros. DS is a no go for us.

-thegamefreak0134
_________________
What if the hokey-pokey really is what it's all about?

[url=http:/www.darknovagames.com/index.php?action=recruit&clanid=1]Support Zeta on DarkNova![/url]

thegamefreak0134 wrote:

(3) Apparently (for what it's worth) Nintendo is going to make a DS version. There was a very good looking DS Smash Bros. Homebrew going already, and nintendo fined the project coordinator $150,000 for it. Smash Bros. DS is a no go for us.

Nintendo fined a guy 150,000 for making a fan game? Can you give a link to proove this statement?

I don't remember the link offhand, but it would hardlyt qualify as a fan game. They were making a fully-working version of super smash brothers for the Nintendo DS. Not only was the project canceled, the project pages were taken down by their respective hosts because of it. Do a google for smash bros DS and it should come up eventually. Needless to say, that scared me slightly. The only reason I'm fairly sure we're safe is because the GBA is most certainly dead, save to 3rd party developers. (Although I still play it a bunch.)

Anywho, work on the project may seem slow, but we're in the process of data collection. Regardless of artwork, we are going to attemt to "borrow" the physics and state timing from the gamecube version, since we can apparently see all of it in the debug menu. (Nice little feature.) At some point, once we have a character more developev, I want to throw some sound in there. I've been working on a nice bit of intro music, but I don't quite have an arrangement for a level going, or much less a level to put it with.

We need to re-work the camera engine a bit, add death and camera boundaries to the level, and generate the first hit of the game before I release the next demo. These are small things, but the first two will make the demo "glitch free" and the third will be an actual achievement.

-thegamefreak
_________________
What if the hokey-pokey really is what it's all about?

[url=http:/www.darknovagames.com/index.php?action=recruit&clanid=1]Support Zeta on DarkNova![/url]

is Smash Bro's Advance still in development?

just wondering because its been a month since you posted.

I do hope you continue!
_________________
popcorn

Yeah, we're still going strong. We've got some people pulling images for us from the original (SSBM) to base the physics on, so we should have a more complete character going soon. Then it's a matter of adapting our artwork to the physics there to make the character complete. (Thus, the first "additions" will basically be images pulled from the gamecube, not our artwork. Sorry about this, but we need to work on the engine as top priority.)

As a matter of fact, I got the basics for platforms, both stationary and moving, going this week. With the system, I believe it will veen be possible to make extremely complex levels (like levels that rotate, similar to brinstar depths) without too much trouble. Not nearly as complex of course... This is a GBA.

I'll let you know as soon as we have something a little more impressive to showcase, as we're (still) researching stuff.

-gamefreak
_________________
What if the hokey-pokey really is what it's all about?

[url=http:/www.darknovagames.com/index.php?action=recruit&clanid=1]Support Zeta on DarkNova![/url]

awesome! I can't wait to see how this turns out!
Is there a test file out soon?
_________________
popcorn

Idealy the test file will be hosted at thegamefreak0134.googlepages.com in the Projects section. However, since my internet is a bit limeted at the moment, the pages are being updated rather slowly. The file there currently is an onder file, and the Smash Bros ADVANCE page needs updating. However, once my connection is a bit more stable I'll definately post it there.

-gamefreak

PS: Not as limeted as I thought though. Natso has set up a nice (private, don't go asking for the address) proxy that I can use to view the site from school, so expect more contact (and updates) in the future.
_________________
What if the hokey-pokey really is what it's all about?

[url=http:/www.darknovagames.com/index.php?action=recruit&clanid=1]Support Zeta on DarkNova![/url]

Hey, thegamefreak0134, can you post a link to you're awesome GUI State Editor? Please?

I'm making a game that includes your State coding (it does include your copyright stuff), but I was wondering if I could use your State Editor. It's OK. Feel free to tell me "NO! **** and **** and you can never ****ing using my ****ing code again, you ****ing **** **** ****!!!!!!!!"

Hopefully, though, you won't say that.
_________________
Knock-knock.
Whose there?
Kirby.
Kirby-who?
I told you! Kirby!

Kirby wrote:

I'm making a game that includes your State coding (it does include your copyright stuff), but I was wondering if I could use your State Editor. It's OK. Feel free to tell me "NO! **** and **** and you can never ****ing using my ****ing code again, you ****ing **** **** ****!!!!!!!!"

Hopefully, though, you won't say that.

What a strange way to ask for code.

-Brendan

sgeos wrote:

Kirby wrote:

I'm making a game that includes your State coding (it does include your copyright stuff), but I was wondering if I could use your State Editor. It's OK. Feel free to tell me "NO! **** and **** and you can never ****ing using my ****ing code again, you ****ing **** **** ****!!!!!!!!"

Hopefully, though, you won't say that.

What a strange way to ask for code.

-Brendan

Yes, I know it's strange. I'm just trying out different ways of "asking" for things, to see what people like best. That way, it's easier to get replies faster (that's my experience anyway)
_________________
Knock-knock.
Whose there?
Kirby.
Kirby-who?
I told you! Kirby!

Actually, I am going to say no. This is not to be mean or anything, I would just like to contain the code in this project for the time being. The main reason I want to do this is because the state system and editor are highly un-finished, and I don\'t really want to release them to the public yet. I posted the code for review, not for example, since it\'s not the best code in the world. Feel free to use the basic concepts, but I would feel a lot better about it if you coded it yourself. (You\'ll get better experience that way anyway.)

The basic way it works is simple. You define a series of states for a character. This state has a set length after which it jumps to another state, which can be itself again. It has all of the attributes for the particular character type defined (things such as physics, color, movement, etc.), but those values are only loaded at the beginning of the state, and then only if needed. The state also has a block of code associated with it. This code is executed every frame, and dictates things like controll with the keys, or acceleration of values, or even the creation of projectiles and things.

As such, you operate a character in this system by creating the character in their opening state, then running through the system to increase their frame, display that particular frame for the state, update the appropriate values, and call the state\'s block of code for execution. Once you call the first state, you only have to worry about the character when you want something to interact with them. (For instance, if a projectile hits the character you may throw them into an \"ouch\" state of sorts.)

BTW, in my system the states are separate from the collision detection. However, if a state doesn\'t handle the response to a collision, nothing happens. This may or may not work for you, it depends on the game.

I hope this was helpfull. I\'ll stress this again, I would really prefer you write the system yourself, as mine is highly un-finished and un-tuned...

-gamefreak
_________________
What if the hokey-pokey really is what it's all about?

[url=http:/www.darknovagames.com/index.php?action=recruit&clanid=1]Support Zeta on DarkNova![/url]

thegamefreak0134 wrote:

Actually, I am going to say no. This is not to be mean or anything, I would just like to contain the code in this project for the time being.
-gamefreak

That's OK. And anyway, when I ported the code to do AI, I had to change a lot of it anyway.

Oh, also, I just wanted to say I think you're Super Smash Bros game is going really well.
_________________
Knock-knock.
Whose there?
Kirby.
Kirby-who?
I told you! Kirby!

Do you know what you are going to use for audio? If it includes a MOD Player, great. I know where you can find some great MOD music. Goto http://www.modarchive.com/, Click on Advanced Search, File Types to Search for is .mod, and then try "kirby" and "mario" in the search box. They are pretty good.

EDIT: Actually, only try "mario". I think the kirby song is a .it.
_________________
Knock-knock.
Whose there?
Kirby.
Kirby-who?
I told you! Kirby!

But is the stuff on Mod Archive free to use in your own projects?
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

tepples wrote:

But is the stuff on Mod Archive free to use in your own projects?

Yes, so long as you include the copyright data.
_________________
Knock-knock.
Whose there?
Kirby.
Kirby-who?
I told you! Kirby!

We plan on using Krawall for the sound, basically because I will be doing the sound almost entirely myself and I'm more comfortable with it than anything else. As for the music, I'm not evenn going to visit the archive, because I will be composing arrangements of the various character themes specifically for this game. That's actually going to be one of the more fun parts of the project, and it's why we're working on it last. Don't expect any music for a while, unfortunately...

-gamefreak
_________________
What if the hokey-pokey really is what it's all about?

[url=http:/www.darknovagames.com/index.php?action=recruit&clanid=1]Support Zeta on DarkNova![/url]

thegamefreak0134 wrote:

We plan on using Krawall for the sound, basically because I will be doing the sound almost entirely myself and I'm more comfortable with it than anything else.

I use Apex Audio System. It's really good and works much better than Krawall.

Also, thanx for the advice with the state system. I wrote my own editor and it works great.
_________________
Knock-knock.
Whose there?
Kirby.
Kirby-who?
I told you! Kirby!

Any updates or Images?

I already told you about the platforms right? OK.

I have only one real update: Our home-site has moved. Natso has given me some nice webspace, so the new url is: darknovagames.com/newfolder/

Should be easy enough to figure out. The layout is the same, but I\\\'ve updated the Smash Bros. page, and there\\\'s some interesting stuff on my pokemon project for the TI. (please no discussion about that here, the project page for it is at maxcoderz.org in the announce your projects section. Thanks)

I will post my screens and the newest build there today if I can, sometime this week at the latest. It just includes the platform code, but it\\\'s suprisingly fun to be able to walk \\\"on-air\\\" over mario\\\'s head. (I haven\\\'t quite solidified actually drawing the platforms, just the collision with them.)

Have fun. Will post pictures there soon.

-gamefreak

*edit* sorry about all the slashes, my proxy is good but not quite that good... It keeps doing that. I would use the regular unfiltered internet, but alas! I have it not.
_________________
What if the hokey-pokey really is what it's all about?

[url=http:/www.darknovagames.com/index.php?action=recruit&clanid=1]Support Zeta on DarkNova![/url]

excellent thanks for the update! when can we expect to see a release?
_________________
If anyone needs a dragonball online email me @ aaronthejester@hotmail.com

Youre pushy, arent you? The latest release will be included on the site once I post the link, and it will simply include the invisible platform above mario. I intend to completely rework a lot of the actual engine to get the characters to work right, and thus we will not make another release until we have an entire character (probably mario) working. This release will actually be enough to constitute an entire game. However, we may make a few teaser releases as we get bits of him up and running. I will be sure to let you know when we do.

-gamefreak
_________________
What if the hokey-pokey really is what it's all about?

[url=http:/www.darknovagames.com/index.php?action=recruit&clanid=1]Support Zeta on DarkNova![/url]

Thanks alot
_________________
If anyone needs a dragonball online email me @ aaronthejester@hotmail.com

8-D No problem!
_________________
What if the hokey-pokey really is what it's all about?

[url=http:/www.darknovagames.com/index.php?action=recruit&clanid=1]Support Zeta on DarkNova![/url]

cool work on SSB GBA any new updates or images?
_________________
If anyone needs a dragonball online email me @ aaronthejester@hotmail.com

Well, finally an update, sort of. We have started importing images from the gamecube versions to use as placeholders and to help us with both physics and state lengths, to keep the feel intact. Although we will be replacing these images with artwork of our own, I must say that for taking a gamecube model down to a 16-color sprite, they look very nice on a GBA. We will be keeping them in for a long time as we develop the game, but we do not intend to keep them in the final product, so please don\'t get all huffy.

It took me a grand total of 3 days of almost non-stop work to convert the 110 images that make up kirby\'s standing state down to useable data. A lot of that was figuring out how to do it, however. I should be able to complete around 100 images in a day, so expect his progress to improve considerably. (We are not releasing again so soon, due to the fact that his actions range from standing to (gasp!) standing) We also need to re-work the camera routines to accomidate 64x64 sprites and we need to double the overall level size, as the larger sprites make the smaller levels look like you are playing in giant melee mode.

Overall though, we are breathing new life into the project. Expect a good release in a few weeks.

-gamefreak
_________________
What if the hokey-pokey really is what it's all about?

[url=http:/www.darknovagames.com/index.php?action=recruit&clanid=1]Support Zeta on DarkNova![/url]

any1 know when the last post was made on this? im tyring to help out on the project or even get help with mine... sum1 email me when thou dost return kk?
_________________
Current Project-
>Super Smash Game Bros Advance

Hello all! It's time to wake up!

After quite a while of little to no development thanks to school and difficulties finding times to meet and work together, we have decided to resume development on this project.

As we take up the project again, we want to integrate some of the old logic that we had. We will, however, begin mostly from scratch. To begin with, we do want the game to be true homebrew, and as such, many things have been renamed. First off, the game name has been changed to "Sensational Smack Brethren Clash" to reflect the initials of the series, along with a subtitle similar to the Nintendo line of thinking (e.g. Melee, Brawl) and to (hopefully) stay away from copyright issues. (I don't think Nintendo has "SSB" copyrighted.) In the light of character graphics, we may use ripped placeholders during development but they will be replaced with original graphics before the final release. Reguarding the possibility that Nintendo may have rights to the characters and their likenesses, according to the debate teacher at our school there have to be eleven differences between two pieces of art in order for the second one to be considered original. We do intend to make those differences in our artwork. Secondly, many character names have been changed, and are currently as follows:

Dr. Mario - Cask MD
Mario - Cask
Luigi - Verdant
Bowser - Squalid
Peach - Apricot
DK - Obdure Ape
Captain Falcon - Lt. Eagle
Gannondorf - Nokyuus
Ice Climbers - Gelid Twins
Kirby - Amaranthine
Samus - Aegis
Zelda - Wicca
Link - Swad
Young Link - Callow Swad
Pichu - Piroot
Pikachu - Jovi
Jigglypuff - Creoon
Mewtwo - Cerebral
Mr. Game&Watch - Sir Tonish

*Please note that a few characters were not included in this list but may be included later.

Naturally, none of the character names are considered final. We can (and probably will) change some of their names in the end. We may also add or remove some characters (particularly some of the clones).

More importantly, we think we're starting out the right way this time! We've seen that it is better to use separate source files for data and se also plan to modulize our code. We have upgraded to devkitARM and are using makefiles. We are actually doing some planning before we delve straight into programming. The future looks much better than it did about a year ago (development-wise) even though we did make some headway.

As far as anything relating to actual development, there is good news. I came up with a menu concept quite recently and it has already undergone a few transformations. It is also being integrated into our theme - a board game. We already have ideas for the character select screen and stage select screen. Now I know some of you are looking at this and thinking that a menu is no big deal and want to actually get to the gameplay - it will come in due time. Remember: you get to those battles through the menu. We intend to make it look good.

All in all, the project isn't dead and progress is being made. I think that is a good thing.

Until next time,
Perfection

P.S. Once again, we apologize for the slashes. The proxy does it automatically.

*Edited for spelling mistakes. (Not like any of you care, though...)

Last edited by The_Perfection on Tue Mar 13, 2007 3:23 am; edited 1 time in total

Heh, some nice names there. I look forward to seeing this project completed.

That 11 differences rule is interesting, do you have any more information? I'd be interested to see what sort of things count as a difference - new background, a pixel or two changed, etc?
_________________
I'm a PSP hacker now, but I still <3 DS.

We're investigating into the whole image copyright thing later. Of course, we also want to know what the limits of fan-art are, and if for instance a fan-game qualifies. However, these issues will be completely resolved at a later date.

Can I ask a mod to edit The_Perfection's post and remove the slashes? Our school filtering technology where the post was made calls for some, well, alternate measures to access this site, and those measures are where they came from.

Anywho, expect to see some serious progress. I am already designing the concept work for said menus, and we intend to have the majority of the system mapped out.

Why are we focusing on the menus first? Because it's a nice easy way for us to get a "battle" through it's start phase, and mainly so we can set starting battle options for test without having to recompile the entire game every time.

The_Perfection is also working on what should be a really cool library for us to use. It will allow us to compile the game to run on GBA and NDS systems, with special defines to make the DS video modes and such work, and mainly so we can debug things on the bottom screen while showing video on the top screen. Provided it works, it will be very useful for testing, and if it becomes good enough we might even publish it. It's pretty hand-tailored to SSBC at the moment though...

Anywho, we're at it again. The official thread for this game is about to be re-located to our official NewFolder forums, but we will keep you all filled in with the major updates. (like new releases, cool screenshots, etc.)

-thegamefreak
_________________
What if the hokey-pokey really is what it's all about?

[url=http:/www.darknovagames.com/index.php?action=recruit&clanid=1]Support Zeta on DarkNova![/url]

Any progress on this game yet?
_________________
If anyone needs a dragonball online email me @ aaronthejester@hotmail.com

Thanks for the compliments on the names. Most of them were taken almost directly out of an old thesaurus. Which ones do you like the best out of the current set?

Unfortunately, I do not have any more information as far as the 11 differences goes, but I think it is safe to assume that they need to be noticable differences. A brand new background - not one that has been slightly modified - most likely counts as a difference, but I do not think that it is safe to just change a few pixels here and there. In fact, I was conversing with someone who had the idea of making the palettes the slightest bit darker. (You know, 15 colors = 15 differences.) I didn't think that was a safe way to go. So I'm betting it has to be a noticable change. That's gonna be hard to do with some characters though. (The ones that really don't have 11 identifying marks on them, you know?)

Hello, jester. I remember you... the one who pestered us about development progress, and here you are again. Just so you know, the menu is being mapped out, and there is some graphic design behind the whole thing. Got a decent menu button done today, and it looks like we're going to use it too. Once I get some really nice renders, we may begin coding the menu map so that we can have a contiguous background moving around.

In short, no coding done, but some menu stuff has been planned and drawn.

It is strangely quiet in this topic now that we are no longer being somewhat controversial with the whole copyright thing... either that, or just about everyone has lost interest.

Thank you to whoever removed the slashes from my post, it makes it quite a bit more readable. (Although I forgot to do a spell check on it first, argh.)

'Til then,
Perfection

well, if you want people to be interested, you gotta give the impression that your project is progressing, and put up some pretty pictures or somethin'

Ant6n wrote:

well, if you want people to be interested, you gotta give the impression that your project is progressing, and put up some pretty pictures or somethin'

This is entirely unfinished, but it's at least something to show progress. We're in the middle of graphic design right now, and going into some severe project planning stages.

http://www.darknovagames.com/newfolder/Screen_001.png

So there.

-thegamefreak
_________________
What if the hokey-pokey really is what it's all about?

[url=http:/www.darknovagames.com/index.php?action=recruit&clanid=1]Support Zeta on DarkNova![/url]

Edit: Nevermind, it worked.

gbadev.org forum archive

Game Design > Smash Bros. Advance

#77866 - thegamefreak0134 - Mon Apr 03, 2006 5:53 pm

#77870 - sajiimori - Mon Apr 03, 2006 6:46 pm

#77874 - thegamefreak0134 - Mon Apr 03, 2006 7:51 pm

#77885 - sajiimori - Mon Apr 03, 2006 9:40 pm

#77886 - Miked0801 - Mon Apr 03, 2006 9:47 pm

#77904 - poslundc - Mon Apr 03, 2006 11:30 pm

#77935 - Miked0801 - Tue Apr 04, 2006 3:23 am

#77937 - tepples - Tue Apr 04, 2006 3:32 am

#77992 - Dan2552 - Tue Apr 04, 2006 12:35 pm

#78024 - sajiimori - Tue Apr 04, 2006 6:25 pm

#78089 - The_Perfection - Wed Apr 05, 2006 2:34 am

#78147 - Natso - Wed Apr 05, 2006 12:59 pm

#78161 - thegamefreak0134 - Wed Apr 05, 2006 5:02 pm

#78184 - tepples - Wed Apr 05, 2006 8:45 pm

#78234 - gauauu - Thu Apr 06, 2006 2:30 am

#78286 - thegamefreak0134 - Thu Apr 06, 2006 1:54 pm

#78308 - thegamefreak0134 - Thu Apr 06, 2006 5:30 pm

#78331 - Natso - Thu Apr 06, 2006 10:18 pm

#78332 - thegamefreak0134 - Thu Apr 06, 2006 10:22 pm

#78334 - sajiimori - Thu Apr 06, 2006 10:46 pm

#78344 - Natso - Fri Apr 07, 2006 12:11 am

#78358 - thegamefreak0134 - Fri Apr 07, 2006 12:42 am

#78359 - Natso - Fri Apr 07, 2006 12:45 am

#78480 - thegamefreak0134 - Fri Apr 07, 2006 4:54 pm

#78815 - Natso - Sun Apr 09, 2006 11:54 pm

#78958 - thegamefreak0134 - Mon Apr 10, 2006 9:37 pm

#79061 - gauauu - Tue Apr 11, 2006 8:44 am

#79108 - thegamefreak0134 - Tue Apr 11, 2006 7:05 pm

#79116 - sumiguchi - Tue Apr 11, 2006 7:20 pm

#79126 - thegamefreak0134 - Tue Apr 11, 2006 7:54 pm

#79130 - tepples - Tue Apr 11, 2006 8:10 pm

#79181 - chishm - Wed Apr 12, 2006 1:19 am

#79182 - sgeos - Wed Apr 12, 2006 1:26 am

#79189 - tepples - Wed Apr 12, 2006 1:44 am

#79197 - gauauu - Wed Apr 12, 2006 2:26 am

#79280 - thegamefreak0134 - Wed Apr 12, 2006 5:52 pm

#79287 - waruwaru - Wed Apr 12, 2006 6:33 pm

#79292 - DekuTree64 - Wed Apr 12, 2006 6:51 pm

#79296 - tepples - Wed Apr 12, 2006 7:06 pm

#79306 - thegamefreak0134 - Wed Apr 12, 2006 7:56 pm

#79308 - DekuTree64 - Wed Apr 12, 2006 8:06 pm

#79320 - keldon - Wed Apr 12, 2006 10:31 pm

#79322 - Natso - Wed Apr 12, 2006 10:35 pm

#79328 - waruwaru - Wed Apr 12, 2006 10:50 pm

#79334 - tepples - Wed Apr 12, 2006 11:35 pm

#79344 - sgeos - Thu Apr 13, 2006 1:32 am

#79422 - thegamefreak0134 - Thu Apr 13, 2006 4:54 pm

#79464 - waruwaru - Thu Apr 13, 2006 9:39 pm

#79510 - sgeos - Fri Apr 14, 2006 1:54 am

#79961 - thegamefreak0134 - Mon Apr 17, 2006 6:04 pm

#79963 - tepples - Mon Apr 17, 2006 6:15 pm

#79977 - Dan2552 - Mon Apr 17, 2006 9:36 pm

#79978 - keldon - Mon Apr 17, 2006 10:01 pm

#79986 - thegamefreak0134 - Mon Apr 17, 2006 11:40 pm

#80013 - gauauu - Tue Apr 18, 2006 2:20 am

#80017 - sgeos - Tue Apr 18, 2006 2:36 am

#80018 - keldon - Tue Apr 18, 2006 2:43 am

#80049 - sgeos - Tue Apr 18, 2006 8:27 am

#80436 - thegamefreak0134 - Sat Apr 22, 2006 6:03 am

#80440 - sgeos - Sat Apr 22, 2006 8:10 am

#80448 - thegamefreak0134 - Sat Apr 22, 2006 9:57 am

#80465 - Natso - Sat Apr 22, 2006 2:21 pm

#80686 - thegamefreak0134 - Mon Apr 24, 2006 8:31 pm

#80698 - Fenderocker - Mon Apr 24, 2006 9:46 pm

#80773 - sgeos - Tue Apr 25, 2006 1:47 pm

#80794 - thegamefreak0134 - Tue Apr 25, 2006 5:54 pm

#81055 - Natso - Wed Apr 26, 2006 10:53 pm

#81706 - thegamefreak0134 - Mon May 01, 2006 4:31 pm

#81746 - tepples - Mon May 01, 2006 9:09 pm

#81750 - keldon - Mon May 01, 2006 9:15 pm

#81793 - edwdig - Tue May 02, 2006 4:28 am

#81844 - sgeos - Tue May 02, 2006 1:28 pm

#81893 - thegamefreak0134 - Tue May 02, 2006 5:49 pm

#81912 - keldon - Tue May 02, 2006 8:17 pm

#81985 - sgeos - Wed May 03, 2006 6:31 am

#82251 - thegamefreak0134 - Thu May 04, 2006 7:57 pm

#82263 - sumiguchi - Thu May 04, 2006 9:34 pm

#82315 - DakeDesu - Fri May 05, 2006 3:46 am