This page is a mirror of Tepples' nesdev forum mirror (URL TBD).
Last updated on Oct-18-2019 Download

[President] Remembering collected items without extra RAM?

[President] Remembering collected items without extra RAM?
by on (#41485)
I've run into a problem: I'm sick of remaking Tetris.

Now I want to make a platformer similar to the Super Mario series, intended to be ROM-hacker-friendly. The player can pick up coins and power-ups from levels, but I don't want the player to be able to grab an item, move the camera two screens away, and then come back and grab the same item again.

But is this feasible without PRG RAM? Eventually I (or a ROM-hacker using my engine under license) might want to put a game on a cart to sell, and I'd imagine that the parts for SNROM-clone (MMC1 CPLD, extra 6264) are a lot more expensive than the parts for UNROM-clone (74HC161, 74HC32). Or should I just bite the bullet and spring for PRG RAM?

Several platformers for NES that have backtracking (Zelda II, Metroid, Kid Icarus, SMB2, SMB3) have 8 KiB of PRG RAM on the cart to remember what coins have been collected, which ? blocks have been opened, which bricks have been broken, etc. Games without PRG RAM either have a tiny level (Lode Runner, Crystal Mines), or lack backtracking (e.g. Super Mario Bros., Contra, Rainbow Islands, Battletoads), or have the vast majority of items comd from defeated enemies (e.g. Mega Man series). Gregg Iz-Tavares and Dan Chang recognized this in the the M.C. Kids post-mortem: "Without the extra RAM, we would have most likely have been forced to redesign the game either so levels didn't have to be modifed or so that it only scrolled in one direction."

Here's what the memory map looks like so far:
  • 0000-00FF: zero page, including state of level decoder
  • 0100-019F: VRAM transfer buffer
  • 01A0-01FF: stack
  • 0200-02FF: OAM buffer
  • 0300-03FF: unknown, much of it to be occupied by the music engine
  • 0400-05FF: state of 16 active objects
  • 0600-07FF: 32x12 metatile decoded section of map centered on player

I guess my internal debate is whether to make something like SMB1 (which has no backtracking) or to make something more flexible like SMB3 (which would pretty much need the entire map decoded to RAM first).

by on (#41493)
Honestly, what I'd do is organize all items/powerups in the level in a list of some sort. This list holds their coordinates, and information about the power up. This is in ROM. Then you make an array of flags in RAM which hold answers true or false to indicate whether an item has been taken. Say the player takes the 3rd item in the list. The third bit from the left in the first byte of the taken-status flags would be set. Since it's one bit per power up, that saves you RAM. If you plan on having 2048 power ups or coins, then that'll be 256 bytes.

I think if you're closer to being able to get away without using WRAM than not, you should try and avoid WRAM. The only reason I use it is because my game is a new Castlevania style game where there are lots of RPG aspects and you save your game. Since I basically had to use it to save games, I allowed for 3 save files, 1k each, leaving me 5k of RAM to work with. But if you're not planning on saving your game, I think you can get away without it.

by on (#41499)
Quote:
I've run into a problem: I'm sick of remaking Tetris

Honnestly, it's about time.

I think it should be possible to have backtracking and flags for items without extra cartridge RAM. In my game engine, the levels are separed into screen and each screen can hold up to 8 objects. There is a 64-byte table in the system RAM that holds one flag for eacah possible object in a 64 screen level, so that when the player opens a chest in the level it remains open until the player either gets a game over condition and have to do the level again, or beats the level. If he just loose a life but not game over yet, the flags aren't touched so that he cannot collect items more than once.

If you look carefully at Mega Man games, there is often extra life or energy capsules in levels that are not dropped by enemies, and those don't reapear when you exit the screen and come back if you picked them. Yet no Mega Man game ever used extra RAM.

The reason SMB3 needed extra RAM is because there is many coins and bricks that can be picked/destroyed, much more than 8 per screen. In that case yes extra RAM can be needed.

by on (#41501)
I don't remember much of the memory map I was planning on using, but I'm pretty sure my Sonic engine could almost work with just 2KB of RAM. When I decided to add 8KB of RAM I indeed moved the object states there, but just because it made the object definitions easier to read (which can be hard when scrolling in both directions, shouldn't be a problem for side scrollers). The other things that reside in PRG-RAM now are the complete level map (it could be in ROM instead) and the currently active objects (I did this to increase the number of those from 16 to 32).

The bottom line is that the PRG-RAM I'm currently using isn't really necessary, it just made things a bit easier and more flexible. This means that the basic idea could probably be realized with just 2KB. If you have a bit for each object in the level just to tell if they're dead or alive, you could track 512 objects with just 64 bytes (I'm sure you can fit that in your memory map). Since 1 bit might not be enough for some objects (that need to remember more than alive/dead), I made some extra memory available (128 or 256 bytes, can't remember), and the object definitions of these objects contained a pointer to the byte to be used for this purpose (since there are few bytes, the pointer is only 8 or 7 bits). Technically you could even use a few consecutive bytes if the object is really complex and really needs them, there is no 1 byte per object limit.

That's it, I think you can keep track of a lot of things with 1 bit per object in the level and a few extra bytes for more complex objects.

by on (#41502)
I think this is one of those things that gets weeded out in design - how big and complex do your levels need to be? Once you've got an average level figured out, you can see how much data you'll need to store.

I would tend to think similarly to the others here, you should be able to track one level's worth of objects with individual bits. Of course I don't know how commercial games did it at the time, perhaps there's something about that approach that just won't be enough.

You could also do something in between: make levels that are non-backtrackable after a certain point. You go through a door and there's no door to take you back, or you jump off a high ledge into the next screen below and there's no going back. These would be the halfway points of the levels, the checkpoints. A simple one way door would be easiest to explain to the people making their own levels.

by on (#41506)
Zelda used a lossy scheme for storing enemies; you could defeat some of the weaker ones in a room, exit, and re-enter to find the stronger ones converted to weaker ones. I think a lossy scheme could usefully work to reduce storage space below one bit per item. You could divide the level into sub-sections, group objects and enemies into classes, and keep track of the number of objects for each class in each sub-section. I think there are some creative things that can be done in approximating what things were left. Of course such a scheme could only be used for common things like coins or filler enemies; special items and bosses must be remembered precisely.

by on (#41507)
blargg wrote:
Zelda used a lossy scheme for storing enemies; you could defeat some of the weaker ones in a room, exit, and re-enter to find the stronger ones converted to weaker ones. I think a lossy scheme could usefully work to reduce storage space below one bit per item. You could divide the level into sub-sections, group objects and enemies into classes, and keep track of the number of objects for each class in each sub-section. I think there are some creative things that can be done in approximating what things were left. Of course such a scheme could only be used for common things like coins or filler enemies; special items and bosses must be remembered precisely.
I think such a system would work fine for enemies, which are alive and their positions can change, but I know I would hate to pick up a few coins out of a big square of them and come back to find the remaining coins rearranged. I can understand a system like that from a programming perspective but not a gaming one.

Also to address earlier points about how much object data needs to be stored, I think Mario needed extra RAM for situations like this:

Image

Big piles of interactive objects that have changing states. If your engine doesn't need that, you could do fine with less RAM. Admittedly it is more fun knowing you can break down that whole pile and there might be something hidden in the middle.

by on (#41509)
UncleSporky wrote:
Big piles of interactive objects that have changing states.

You're right about that. In fact, there's an even more pathological case of deformability that I want my engine to be able to handle: WORLD 1-2 from the original Super Mario Bros. Think of the amount of data that one would need to store for all the brick blocks in that map.

by on (#41512)
tepples wrote:
UncleSporky wrote:
Big piles of interactive objects that have changing states.

You're right about that. In fact, there's an even more pathological case of deformability that I want my engine to be able to handle: WORLD 1-2 from the original Super Mario Bros. Think of the amount of data that one would need to store for all the brick blocks in that map.

I just counted because I am bored. There are 263 breakable blocks in 1-2. 135 more brick tiles are not breakable due to being grounded but I imagine they are stored the same way (and if it were Mario 3 you could use a shell or your tail). There are 11 tiles that are ? blocks, hidden powerups and such. 21 enemies and 17 loose floating coins.

That's 447 things in the level that are interactive and would need at least 1 bit to indicate whether they still exist in their original state. (The multi coin blocks would require more.) If all you needed was 1 bit each that's 56 bytes for the whole level not including the pipe detour, ending staircase, or anything else I might've missed.

I think that's doable, especially if you used a one way door and split it in half, but at the same time you could build a much more robust and flexible engine with more RAM. It sounds like if you were going to make a nice Mario 3-esque game you would personally go for more RAM, and you should do it however you want. Personally, I have more fun trying to do more with less. :)

by on (#41515)
Why can't I vote "SMB3 clone without PRG RAM"? Seriously, I think that's very possible. Of course you'd have to look away from the obvious and give up on decoding large sections of level maps to RAM, coming up with a decent scheme for reading maps from ROM instead.

by on (#41518)
tokumaru wrote:
Why can't I vote "SMB3 clone without PRG RAM"? Seriously, I think that's very possible. Of course you'd have to look away from the obvious and give up on decoding large sections of level maps to RAM, coming up with a decent scheme for reading maps from ROM instead.


I was wondering the same thing. I would've voted for SMB3 without WRAM too.

by on (#41519)
Celius wrote:
I was wondering the same thing. I would've voted for SMB3 without WRAM too.

Yeah, I just voted wrong because I though the first option said "SMB3" (kinda assumed that from reading the post, instead of actually paying attention to it). I just realized what was actually written when my vote was already being sent. Yeah, that one vote is from me and it's wrong. Sorry. =P

by on (#41521)
tokumaru wrote:
Of course you'd have to look away from the obvious and give up on decoding large sections of level maps to RAM

By "large sections" do you mean bigger than the 32x12 metatile buffer that I already envision?

by on (#41522)
I just voted for SMB3 because I'd prefer to see a more fully-realized game, whatever you have to do with RAM.

It can be difficult in cases like this. It's a lot of trouble to try to squeeze a good game in with less space, and you may not be satisfied in the end. But you're already going to the trouble of making a NES game which is enough of a headache by itself! What are you thinking, making a NES game, you crazy person?!

by on (#41526)
tepples wrote:
By "large sections" do you mean bigger than the 32x12 metatile buffer that I already envision?

I'm still not sure. 32x12 = 384 bytes does seem like quite a waste to me, and enough to remember the states of a lot of objects! I'd probably prefer compressing the level maps using a scheme that is not so slow to decode in real time but still compresses fairly well.

by on (#41528)
You guys who have made full games before, what does your RAM look like? How much do you devote to each task? How much for active objects, level maps, random flags and variables?

I've seen incomplete maps for games like Super Mario Bros. and they're always fragmented and hard to read, almost haphazard.

by on (#41529)
UncleSporky wrote:
You guys who have made full games before, what does your RAM look like? How much do you devote to each task? How much for active objects, level maps, random flags and variables?

How many complete homebrew games can you list that had complex level maps and dynamic objects? I can list none. Most have a few constant objects, little to no screen movement, and look pretty comfortable in 2KB.

by on (#41530)
Yes, I could do checkpoints that break backtracking. SMB1 had checkpoints, namely the flagpoles.

UncleSporky wrote:
That's 447 things in the level that are interactive and would need at least 1 bit to indicate whether they still exist in their original state. (The multi coin blocks would require more.) If all you needed was 1 bit each that's 56 bytes for the whole level not including the pipe detour, ending staircase, or anything else I might've missed.

True, I could devote a 64-byte buffer to tracking things that have been interacted with. But how would I associate each interactive thing to an address in this bitfield as the map is decoded?

Backtracking, destruction, no PRG RAM: pick two.

by on (#41534)
tepples wrote:
Backtracking, destruction, no PRG RAM: pick two.

If you don't take the challenge, I will. I was planning on making the Sonic game into something else anyway because a) Sonic physics are way too complex for my little head to recreate; b) I can't sell/spread a game containing a copyrighted character. I know I might fail after all, but right now I feel like taking the challenge, because it just seems possible.

by on (#41535)
Quote:
You guys who have made full games before, what does your RAM look like? How much do you devote to each task? How much for active objects, level maps, random flags and variables?

In fact there is only 2 full games yet, namely Solar Wars and NeSnake 2. None of them implement any scrolling of any sort, and both are not side-scrolling platformers.

Quote:
Backtracking, destruction, no PRG RAM: pick two.

I'd guess it pretty much summaries things well. Altough in Castlevnania, you can pick candles that won't reapear, it is possible to backtrack in a range that is limited by 2 doors and there is no PRG RAM. There is some walls that destroys themselves to leave secrets, but in small quantities (compared to destroyable blocks in SMB games). Also, if you backtrack, the wall will be here again and won't be destroyable.

Oh by the way it's fun but in modern Castlevania games, the candles re-appear when you exit a room and go back in. The NES games too if you take stairs, but not if you just backtrack in the same screen.

Quote:
b) I can't sell/spread a game containing a copyrighted character

Why everyone on this board seems suddently attracted by $$$$ ?

by on (#41561)
i think all a video game needs is player interaction and some sort of goal for the player to aim for, why would it need anything more to be classified as a 'video game'?

i've only made one game which scrolls but doesn't have to account for anything but previously loaded sprites, it all operates in about 1kb or slightly over. to get back on topic i think tepples is right with this:

Quote:
Backtracking, destruction, no PRG RAM: pick two.


if you really want 'destruction' in terms of being able to change any block on map to either a preset alternative or a completely different block altogether it pretty much calls for PRG-RAM. MC Kids programmer cited 600~ bytes or whatever it was to have 1 bit assigned for each block on the map so even the simplest method of having every block on the map being able to be assigned at the very minimum a preset alternate already blows away a huge amount of your RAM budget, and it's still not as flexible as having PRG-RAM levels. i do not have smb3 editors/roms here at the moment i would assume both games which both store levels in RAM would have a similar number of blocks in the level.

smb3 if i remember right mainly has only 1 possible alternate for block destruction (used block for powerups, blank space for smashable bricks). but then there's the multiple coin bocks as has been mentioned along with for example the ice blocks which can have a froze, melted, and collected status. 1bit per block is not enough to handle a game like smb3 because of these special cases.

sprites i think is dead simple alot of games didn't have any trouble with it. a 32 sprite table and you already have the capacity to avoid loading sprites after they've been 'expended' with up to 256 sprites in your level. i don't believe you could recreate smb3 without prg ram without making enormous sacrifices with RAM to get block changes right (2 bits per object is over half your RAM).

by on (#41563)
I've split the fan game copyright discussion to a separate topic.

I thought of two reasonable compromises, selected by a flag per map.

Limit backtracking: Let the player back the screen up a bit, still staying within that two-screen-wide sliding window. If you've played Super Mario Bros. Deluxe for GBC, you might understand what I'm talking about.

Limit interactive object density: Allow only one "interactive" object, such as a coin or ? block, per column. A 64-byte buffer would allow 32 screens between checkpoints, which is wider than the 24 screens of SMB1's 8-1. (Thanks UncleSporky for the map link.)


Oh, and "President" stands for Another Side Scroller Hosted On a Limited Environment. (Die, hinmin!)

by on (#41570)
tepples wrote:
Yes, I could do checkpoints that break backtracking. SMB1 had checkpoints, namely the flagpoles.

I meant the way Mario 3 does it in many worlds. As one example, this door:

ImageImage

Additionally Mario 3 has quite a few autoscrolling levels. Clearly they do these things for gameplay rather than to be economical with RAM but I wanted to illustrate the concept. You don't have to call a level finished in order to clear part of memory and start fresh.
Quote:
True, I could devote a 64-byte buffer to tracking things that have been interacted with. But how would I associate each interactive thing to an address in this bitfield as the map is decoded?

Well here's an interesting thought experiment. You could employ one type of system that would only work for mostly static objects. By this I mean blocks or coins, or blocks that are thrown and destroyed; anything that doesn't leave its origin point and survive. Objects that fall under this category would need a flag. You also need a pointer to where you are in the bitfield, an index for where you are within the byte, and a counter for the total number of bitfield positions currently in memory. (An 8-bit counter could only handle about 2/3 of 30x12 metatiles being filled.)

Set every flag in the bitfield to 1 when the level is loaded. Also at the start of a level, you iterate through the objects currently in memory, incrementing your index and stopping at the far edge of the screen (usually right). As the player runs through the level and new tiles are loaded, you continue to iterate through each new line vertically. If any bits are zero, you don't load that object.

Any time an object is destroyed or otherwise irreversably removed, it leaves behind a special byte at that map location (rather than just turning into a sky tile or something). As objects scroll out of memory and are unloaded, you compare your bitfield (decremented by the counter) with the objects in that column. If they are still present, you leave the 1. If the special byte is present then they have been removed and you write a 0.

This method would not work well for keeping track of a map taller than one screen. If absolutely necessary you could load vertically as well (30x24) since you must continue scanning sequentially for it to work. Note that games such as Mario 3 and McKids never have backtrackable areas more than two screens tall and often have a minimum of objects on the higher screen. If you need to record a second layer of objects such as a front-and-back castle, I can think of no other way than to have a second bitfield.

Extremely cumbersome and with many caveats. Perhaps too slow to work. But that's just the first way that occurred to me, and I'm not very good at figuring this stuff out yet; I'm sure there are better ways. Perhaps a system to divide the map into metascreens and keep track of the objects per screen.

Quote:
Limit interactive object density: Allow only one "interactive" object, such as a coin or ? block, per column. A 64-byte buffer would allow 32 screens between checkpoints, which is wider than the 24 screens of SMB1's 8-1.


See, that's what I mean, you guys are a lot more clever than I. :)

Personally, if I were determined to operate with 2k RAM, I would design my game around the limitation. Rooms with excessive numbers of objects would be non-returnable, utilize checkpoints and autoscrolling levels, etc. It would be an interesting challenge.

This is really your worst case scenario, typically it's going to be far better than this:

Image

By the way, for more study/reference on level design...

by on (#41572)
smkd wrote:
MC Kids programmer cited...

I really think people should stop quoting that guy for the truth. MC Kids is a mediocre game that lacks a lot and in many areas. Any good programmer reading his article can tell many things were done inefficiently and in a half-assed way.

I admit he's got the fact that he finished a game to back him up, something most of us here do not, but that doesn't mean we can't see the flaws in his designs.

Quote:
but then there's the multiple coin bocks as has been mentioned along with for example the ice blocks which can have a froze, melted, and collected status. 1bit per block is not enough to handle a game like smb3 because of these special cases.

Did you read my idea that combines 1-bit flags with multi-byte states? The idea consists on having one bit for every object, and the order in which the objects are arranged in the object table (or whatever you call it) define which bits they use (first object = first bit). There will be some wasted bits, because not all objects need them.

Anyway, in addition to the single bit, complex objects can make use of more memory simply by indicating what part of a block of memory reserved for objects it wants to use. This pointer is in the definition of the object, along with it's coordinates, type, etc. This means that each instance of that type of object can use a different part of that memory block. If you set aside, say, 128 bytes for this block, all the complex objects of the level combined can't use more than 128 bytes for remembering states.

This makes it possible to remember more information about the objects that really need it.

by on (#41616)
Quote:
Limit backtracking: Let the player back the screen up a bit, still staying within that two-screen-wide sliding window. If you've played Super Mario Bros. Deluxe for GBC, you might understand what I'm talking about.

Well, SMB Deluxe is probably limiting the backtracking as the NES version does, but since the GBC screen is smaller, the scroll depending where Mario is on the Screen, and that was cheap in my opinion (aslo the GBC have more system RAM than the NES, and I guess that particular cartridge also have extra RAM with battery).

If you plan to limit the backtracking, it's much more clever to limit backtracking with doors and/or fast scrolling screen split as does Castlevania and Mega Man games respectively. (I guess SMB3 doors counts as well, but they are much rarer than CV doors and done in a different style. In the case show above it's clearly because of raster effects).

Also, a door would look stupid for a game that happens on the outside.

@smkd: Do you really want to turn on your NES and play with a 1k game without music for hours ? I personally dont.

by on (#41627)
tokumaru: mc kids being mediocre doesn't change how many bits there are in a byte and the fact that if you want to assign 1 bit for every block in the level, you need totalblocks/8 bytes. all the author did was run a quick formula based on block counts in his level, how does mediocre programming come into this? i only used it for example's sake.

the pointer into the block of memory for multi-byte states sounds nice, although the limitation irks me (inevitable i guess), to make levels as SMB3 presented them would just need finding the worst case scenario and allocating enough memory for this while still having enough for everything else if that's even possible. i'm not sure how much RAM SMB3 requires, or if i should even keep bringing up SMB3...

how will it be accessed when the player or an enemy touches it? when for example the player touches a block in the level and it needs to change state in this state table, how is it going to reach the associated pointer? sequentially running through the block data until matching coordinates are found would be dead slow. you could have an additional table that for every block buffered (like how SMB1 does it for an area 2 screens wide) an index into this state table is stored for quick lookup with a huge RAM cost. what idea do you have in mind.

could you post a mockup ram map for this layout in the 2kb since it's an interesting topic and i'd like to see how someone else would pull this off.

bregalad: personally i couldn't play any game for hours at a time although lack of music wouldn't push me much closer to the power-off button. not sure what point youre trying to address though.

by on (#41628)
Bregalad wrote:
Well, SMB Deluxe is probably limiting the backtracking as the NES version does, but since the GBC screen is smaller, the scroll depending where Mario is on the Screen, and that was cheap in my opinion (aslo the GBC have more system RAM than the NES

For one thing, the GBC forces one-screen mirroring, with a 10x9-metatile viewable window within a 16-metatile-wide sliding window on the map. (I'm using vertical.) For another, some of the game's puzzles (e.g. 4-4, 7-4, 8-4) rely on the lack of backtracking.

Quote:
If you plan to limit the backtracking, it's much more clever to limit backtracking with doors and/or fast scrolling screen split as does Castlevania and Mega Man games respectively.

But if you have a gate every screen or two, it turns into Pitfall or A Boy and His Blob very quickly. And I always thought Mega Man had the quick scroll because of CHR size limitations.

Quote:
Also, a door would look stupid for a game that happens on the outside.

Not necessarily.

by on (#41629)
Quote:
For one thing, the GBC forces one-screen mirroring, with a 10x9-metatile viewable window within a 16-metatile-wide sliding window on the map. (I'm using vertical.) For another, some of the game's puzzles (e.g. 4-4, 7-4, 8-4) rely on the lack of backtracking.

Yeah I guess it's close to the same size of a NES nametable, but since the screen is smaller it is possible to scroll without glitches. You get a good point here.

Quote:
But if you have a gate every screen or two, it turns into Pitfall or A Boy and His Blob very quickly. And I always thought Mega Man had the quick scroll because of CHR size limitations.

As long as you keep descroyable objects under a certain amont between two doors I don't see the problem. And yes if you do it Mega Man like you could get 2-in-1 (altough you are right Mega Man does this for CHR and not for backtracking, as backtacking is mostly allowed in Mega Man games).

by on (#41631)
For some reason, I get the impression that Mega Man 1 was designed to be a FDS game.

by on (#41639)
smkd wrote:
tokumaru: mc kids being mediocre doesn't change how many bits there are in a byte and the fact that if you want to assign 1 bit for every block in the level, you need totalblocks/8 bytes. all the author did was run a quick formula based on block counts in his level, how does mediocre programming come into this?

It comes in because he used the simple straightforward idea of assigning 1 bit to each block in the level. This is obviously wasteful, because not all blocks will change state. If more thought was given to the problem, a better idea could come up that would make it possible. You can't say something is impossible just because it is so using a specific method. Chances are there is a way to make it happen.

Quote:
i only used it for example's sake.

It's just that is has pissed me off lately that whenever we talk about platform games that article is quoted, probably just because it is the largest compilation of platforming material. But that doesn't mean the information contained there is the standard or the best that can be done for the NES, it's just what worked for that little mediocre game.

Quote:
i'm not sure how much RAM SMB3 requires, or if i should even keep bringing up SMB3...

If tepples wants to clone SMB3, we definitely should be talking about it.

Quote:
how will it be accessed when the player or an enemy touches it? when for example the player touches a block in the level and it needs to change state in this state table, how is it going to reach the associated pointer?

There are many ways to do that. If there were not many blocks, I'd say just treat them as active objects, apply regular object x object collision, and store the pointer to the state memory as part of the object's properties. I can see how this would be slow in cases where there are many blocks.

One solution I can think of is having a rectangular array of blocks as a level object, and it could act as a map within the map.

The fastest way would probably be to hardcode the blocks to map locations, and special metatile codes would be linked to the interactive blocks that change state. Maybe a pointer to the state could be stored right after the metatile type, if the map doesn't require that 1 metatile be defined by only 1 byte. That way, only interactive blocks would have state bits.

Quote:
could you post a mockup ram map for this layout in the 2kb since it's an interesting topic and i'd like to see how someone else would pull this off.

I'd have to think more than I'm willing to right now, but I'll see if I find a suitable RAM map description from an old archive of my project, from when I was still planning it for just 2KB.

by on (#41641)
Divide a level into 8x8 chunks or whatever, and for each chunk include a list of coordinates for dynamic objects. This would be in ROM.

But this of course is completely pointless unless someone is actually making a game intended to run on a NES without SRAM. Just use the RAM because emulators would gladly provide 8k of your computer's memory for your purposes.

by on (#41646)
I can see very few reasons to not use PRG-RAM, mostly being if you can use your ideas without compromising too much. For 8kB/32kB I guess this adds something like $5 to the selling price of a cart, as a high estimate for parts/labor.

I say go for the memory expansion, depending on the game it's either 1983 style with 2kB, or 2009 style with as much as 512kB.

by on (#41654)
But then it becomes CHR RAM, PRG RAM, scanline counter/8 KB PRG banks: pick two. I don't want to have to break a Gyromite and an FF3j, not that I'd want to break any game to make a repro anyway.

As far as I know, the UNROM-clone board from retrousb.com doesn't have any space for the decoder circuit. So I'd have to use an SNROM clone.

U*ROM board: $4.00; needs PRG ROM, CHR RAM, 74HC161, 74HC32, and a few caps+resistors
S*ROM board with CPLD: $9.00; needs PRG ROM, CHR RAM, PRG RAM, and a few caps+resistors
Case and lockout defeat for each: $7.00

Are you trying to say the PRG RAM will cost about as much as the discrete chips?

by on (#41663)
I'd use PRG RAM either if I run out of RAM or if I want battery saves. I've personally never encountered those cases yet, but by all means if you do there is no reason to simplify the engine you wanted to do solely to remove RAM from the cartridge.


Quote:
For some reason, I get the impression that Mega Man 1 was designed to be a FDS game.


I'm pretty sure that Mega Man 1 was designed to be a FDS game, but as the FDS was overall not a commercial sucess Capcom changed their minds. That's why there is separate rooms before the boss fight, the game would be loading from the disk while the player would walk through the room and not notice annoying loading times. Traditionally those rooms remained in all futures platforming Mega Man games.

If tepples clones SMB3 would it be legal? And it definitely wouldn't to sell repros, as that other Sister games for the C64 were forced to stop being sold. After cloning tetris for about 10 years, and seeing all the techincal knownledge and programming skills he has, we could except better games from him.

Quote:
As far as I know, the UNROM-clone board from retrousb.com doesn't have any space for the decoder circuit. So I'd have to use an SNROM clone.

I've made one, but it doesn't work at all (without the SRAM), so I can't know how well the SRAM works.

by on (#41668)
Bregalad wrote:
I'm pretty sure that Mega Man 1 was designed to be a FDS game, but as the FDS was overall not a commercial sucess Capcom changed their minds. That's why there is separate rooms before the boss fight, the game would be loading from the disk while the player would walk through the room and not notice annoying loading times. Traditionally those rooms remained in all futures platforming Mega Man games.

Capcom must have forgotten about the original reason for those screens between then and the later games. Mega Man X6 for the original PlayStation has an 8-second "Warning" screen after the player entered the boss room

Quote:
If tepples clones SMB3 would it be legal?

It'll be far less of a flagrant Mario-clone than Giana Sisters. The idea is to provide a basis for development that's more legit than passing around IPS patches against SMB1.

by on (#41670)
I'm sure there's no way to read from the disk without 100% CPU usage, so it can't load in the background while you fight enemies. No FDS game even plays music while it loads.

by on (#41671)
There should be a way if you don't use the FDS bios routines. You could opperate the motor and reading head once in a while and do the game engine the rest of the time. And there probably wouldn't load so much, just the Boss' graphics and/or AI ?

by on (#41675)
We saw too much on SMB1, So SMB3 is the best cure for this, Since SMB3 isn't disassembled. but SMB1 is, I go for SMB3

by on (#41700)
tepples wrote:
U*ROM board: $4.00; needs PRG ROM, CHR RAM, 74HC161, 74HC32, and a few caps+resistors
S*ROM board with CPLD: $9.00; needs PRG ROM, CHR RAM, PRG RAM, and a few caps+resistors
Case and lockout defeat for each: $7.00

Are you trying to say the PRG RAM will cost about as much as the discrete chips?


Common price for SRAM is about $1, 74HC139 maybe 0.20. Rest of the cost is labor, inspection, stocking the parts, etc.

Also, if you'd use enough boards, they should be cheaper than $4. I've sold a lot of bare Squeedo PCBs for cheap, in larger batches though (50+). But $4 a board, and 50 boards, is a good estimate for getting a custom layout (assuming no revisions needed).

by on (#41723)
If you're already set on a board no simpler than UNROM and really don't want to add an extra chip for PRG-RAM, then using a single 32kb CHR-RAM could be an alternative. Of course, this means you would only be able to do some minimal transfers during vblank, but I think many people seem to overlook that this can be a very usable alternative to PRG-RAM for any RAM that doesn't require frequent access.

Then again, I can see Memblers point about cost of your own effort. It all comes down to why you want to keep away from PRG-RAM. To be able to sell lots of homebrews at a minimal price, or just for the challenge? :)

by on (#41726)
Quote:
If you're already set on a board no simpler than UNROM and really don't want to add an extra chip for PRG-RAM, then using a single 32kb CHR-RAM could be an alternative. Of course, this means you would only be able to do some minimal transfers during vblank, but I think many people seem to overlook that this can be a very usable alternative to PRG-RAM for any RAM that doesn't require frequent access.

This is a very interesting technique. However, how many mappers that actually have this feautre exists and are supported my most emulators ? Okay there is CPROM, but it has very limited PRG-ROM. I don't remember anything else, maybe some obscure famicom mapper. And using a mapper one just made up isn't really rom-hacking friendly.

by on (#41733)
Bregalad wrote:
Quote:
If you're already set on a board no simpler than UNROM and really don't want to add an extra chip for PRG-RAM, then using a single 32kb CHR-RAM could be an alternative. Of course, this means you would only be able to do some minimal transfers during vblank, but I think many people seem to overlook that this can be a very usable alternative to PRG-RAM for any RAM that doesn't require frequent access.

This is a very interesting technique. However, how many mappers that actually have this feautre exists and are supported my most emulators ?


Most emulators are outdated, and if the goal is to get something on cart then it's irrelevant. A hacker that can't switch emulators is probably not a very good hacker. :P

by on (#41884)
Quote:
And it definitely wouldn't to sell repros, as that other Sister games for the C64 were forced to stop being sold.

At this point, I feel the need to elaborate. I didn't mean that I wanted to make level after level of this:

Image

When I say "SMB1 clone", I'm only talking about what I expect the engine to be capable of. I fully expect it to support other play styles. But in the following scene, notice the SMB1-style reuse of cloud tiles for bushes, and the familiar design of chimneys.

Image
[ Zoom in | View design document ]


(If you want a GIMP recipe to make faux NTSC artifacts, just ask.)

by on (#41912)
Honestly, the graphics could be better. Some things are nice, such as the bricks, grass and characters (although pretty small). The brown area is painfully flat, the three-balled trees are really weird, and the rest is too bland. Anyway, since your focus is the engine, that shouldn't matter.

Quote:
(If you want a GIMP recipe to make faux NTSC artifacts, just ask.)

I want a GIMP recipe to make faux NTSC artifacts. Please. =)

by on (#41918)
Quote:
I want a GIMP recipe to make faux NTSC artifacts. Please. =)

Count me in too ! The last version of Nestopia makes screenshots MUCH wider than taller and the image is so distrorted it's not reconizable.
And those graphics looks like they are not possible with the NES, lacking the traditionnal black common in all areas, altough I may be wrong.

As long as there is pipes and coins, chances are that your game will be too close to SMB...

by on (#41924)
tokumaru wrote:
Some things are nice, such as the bricks, grass and characters (although pretty small).

Thanks. But the characters are small for a reason: this scene is drawn with 16px = 1 m.

tokumaru wrote:
The brown area is painfully flat

It's supposed to represent dirt that's buried underground, which in any 3D game would get occluded. Compare how large solid regions are handled in Pinobee for GBA.

tokumaru wrote:
the three-balled trees are really weird

Don't worry: I fully intend to make a counterpart to Lunar Magic.

tokumaru wrote:
I want a GIMP recipe to make faux NTSC artifacts. Please. =)

It's actually rawther similar to the recipe that I use to simulate ClearType:
  1. Image > Scale Image to 512x480 with "None" (nearest neighbor) interpolation.
  2. Filters > Distorts > Video, 3x3, not additive, not rotated.
  3. Filters > Generic > Convolution Matrix, set all entries 0 except the middle row [0 1 1 1 0], divisor = 1.
  4. Filters > Blur > Pixelize, width 1, height 2.
  5. Image > Scale Image to 585x480 with linear interpolation.
I wish I knew Script-fu so that I could just turn it into a macro.

Bregalad wrote:
And those graphics looks like they are not possible with the NES

Click Zoom in > View without artifact simulation > Full resolution. The palettes would be set up as follows:
  • 3F00: sky blue
  • 3F01-3F03: grays, used for clouds, building on screen 2, and half the building on screen 4
  • 3F05-3F07: browns, used for status bar, tree trunk, and other buildings (also used for status bar)
  • 3F09-3F0B: greens and brown, used for grass, tree leaves, and cloud bushes
  • 3F0D-3F0F: not used yet
  • 3F11-3F13: cream sprites
  • 3F15-3F17: red sprites
  • 3F19-3F1B: green sprites
  • 3F1D-3F1F: blue sprites

Bregalad wrote:
As long as there is pipes and coins, chances are that your game will be too close to SMB...

I'd half expect tokumaru to pipe up and mention the pipes and rings in Chemical Plant Zone of Sonic 2.

by on (#42001)
tepples wrote:
I'd half expect tokumaru to pipe up and mention the pipes and rings in Chemical Plant Zone of Sonic 2.

Sorry... Not a big fan of that level... =)

by on (#59055)
The bad news: My laptop died a few days ago.

The good news: I found a six-month-old backup of my laptop's entire home directory on a USB drive. President was missing only one day of work. Perhaps it's a good thing that I haven't worked much on President since then.

by on (#59058)
My laptop died once (wouldn't turn on at all), but a day later it mysteriously came back to life. I had a harddrive that died once 2 (discs wouldn't spin up), then a year later it started working again.