mikejmoffitt wrote:We get it. You like Irem and don't like Metal Slug.
Wait a minute... I thought he liked Metal Slug? Now I'm confused. After seeing so many pictures of Metal Slug animations, I thought that was to say, "Metal Slug is awesome!" Although I'll say honestly that I remember playing those games and enjoying them quite a bit and I don't remember the frame rate particularly bothering me. Super R-Type and Gradius III I remember the slowdown being bad.
tepples wrote:Pressing Save All (Ctrl+S) then Build and Run (Ctrl+R) is pretty instant for me
I agree, although I've taken to Ctrl+Shift+S to save all, after spending too much time looking for a bug due to not all of my includes being saved.
This is surely different for everybody, but I actually feel more rewarded doing the coding. I was dreading it in the beginning but it's really fun. For me, I think it's the satisfaction of achieving the result that I want. With programming, even if the code isn't perfect and still needs a lot of refining, you can get it functioning to output the results you want. With coding, I write a rough version to get it to work, without thinking much about optimizing, and then a rewrite phase to optimize it the best I can. With pixels, your result is what you did. There's nothing under the hood.
None of my graphics are yet exactly where I want them to be, so while I feel rewarded to get close, I feel like I end up getting frustrated because there are things I want to improve and I don't know how to do so. With the code, everything probably still needs a little tweaking, or will need to be adjusted when I add more features, but there are still parts that do exactly what I want them to do, from the perspective of the player.
There's also the fact that I've wanted to make an NES game almost as long as I can remember, so I couldn't possibly hide my excitement from seeing my work running on the console.
Famesfernandez wrote:Nope, though you can copy and paste what you are doing here for others to analyze it then you have to worry about someone saying you used his code without telling him/her. I'm only saying that because ive seen that said at Mugen Fighting Guide. People be bitching about stealing codes but never complain about using resources for sprites or frankenspriting.
I'm curious if anything along these lines has ever happened around here. As far as I can tell, everybody's pretty cool about helping one another out, posting code snippets, and respecting one anothers' work. It's a pretty small group, and as far as I can tell, everybody who's active here is pretty passionate about making their own contributions. Sometimes that contribution is sharing a technique for others to understand and use in their project, and sometimes that contribution is a unique game. It seems like a lot of the members here are also pretty adamant about making their own game completely by themselves.
Espozo wrote:Instead of just making something crappy and improving it along the way, I'm trying to do everything the first time.
I used to think that way, and I have to say it didn't work.
Chock me up as another one who agrees with this.
Famesfernandez wrote:Hense this being a spin off to the RPG to make something short and not so crazy at the moment.
This does seem like a project which could be done much quicker, and would get you some attention for the eventual RPG if you do it.
The radius of the stage will be the same four panel 128x128 (x 4)
I think you may still be confused on this, or I'm misreading.
Screen size is 256x240, so if you're saying that your game area is two screens wide and two tall, the total resolution would be 512 x 480
I'm personally a fan of SMB3 style scrolling for a situation like this. Basically, SMB3 (in a 4 way scrolling level for ex. Lvl 1-1) draws 2 screens vertically all of the time. This lets the screen scroll up and down without even having to load any tiles. Tiles are only loaded when the screen scrolls horizontally.
The standard approach to 4-way scrolling is to draw both rows and columns around the screen area. This has the benefit of allowing for as much scrolling in any direction as you want. It's definitely more flexible, but there are more things to worry about when it comes to corner tiles and things of that nature, and it's probably going to be a bit more processor intensive.
Basically, I'm just saying that if a game or a level only scrolls two screens high, I'm a fan of using the simplified method of scrolling they used in SMB3. Kind of like tepples said, "Do the simplest thing that could possibly work." If you ever feel like opening SMB3 in an emulator, and going to view the nametable, you can see exactly what I'm talking about.
Should be able to make it two players without over kill.
It can surely be done, but adding two simultaneous players adds a lot of concerns.
One thing I would think about, have you ever played Contra on a vertically scrolling stage with two players? If so, then I'm sure you're familiar with the phenomenon my friends and I have termed as "scrollf*cking". In this game, if a player touches the bottom of the screen, they're dead. If the player on the top jumps to dodge a bullet, bottom player dies. It is by far the most annoying part of these games.
I was randomly thinking about this the other day, even though my game isn't going to be two players. I was thinking about how I might address this issue, and I had an idea. What if, when the players were too far apart vertically, the screen split? That way, nobody dies and nobody has to go off screen. If the screen is only scrolling vertically, it would be easy to separate the screen halves and rejoin them when close enough. If the screen scrolls in two directions and one player could leave from the bottom and rejoin on the side, it would make it a little weirder but I'm sure there's a decent solution.
Espozo wrote:If it's a really complex shape and won't work with just a hitbox, you could probably treat it like BG collision then where it sort of checks tile per tile.
Minor issue but I think it would be better to put a hitbox object on top of it. Here's why:
Sword object would have no reason to check against background collisions otherwise. So not having this as a BG object could eliminate the need to do that check in the first place.
BG collisions are generally a bit more intensive than object collisions. This is because BG collisions require finding position on the map, calculating metatiles to read, unpacking collision data, checking multiple tiles, etc. With object collisions, you have the data that you need for the computations available in RAM.
Since collision data is typically tied to metatile data, that means that in most games the smallest unit of collision for BG is 16x16. With an object hitbox, this can easily be changed. It would be easier to make complex shapes out of hitboxes than BG tiles.
Famesfernandez wrote:For the most part the bosses are stationary.
Using scroll splits, you can move a BG object as well. Think of it like this:
You can only create a horizontal line that splits the scroll. No vertical splits.
If, for example, you had the boss on the top portion on the screen and the ground on the bottom, you can set the scroll for the top portion of the screen independently from the bottom, and move your boss.
Basically, you can take your background and slide it around to move your object.
A one man team. Only person I give props to like that is who I mention. Tom Happ for developing Axion Verge by himself.
It's a different sort of thing, but I definitely give props to those who went before, discovered the information about developing for the NES and posted it for the internet. I know I definitely wouldn't be making NES games if people hadn't spent years refining the knowledge base and creating the resources for people to learn how to do so.