This article...
http://nerdlypleasures.blogspot.in/2016 ... r.html?m=1...says that "Chris Covell's Solar Wars" was the first, in 2001.
Is anyone aware of any earlier NES homebrew game?
Also, I'm making a list of NES homebrew games and will write about them on my blog. But, I can't find information on lots of games.
Specifically, does anyone have information on that game Morphcat had on display in Berlin? I can't seem to find even a picture of it. And my last info says it's untitled. ?
Mouser was from 1998, I think:
http://nesdev.com/mouser.zipIt doesn't exactly run properly on hardware though.
There's a bunch of stuff older than 2001 at:
http://nesdev.com/archive.htmlEven some stuff that's older than that by Chris Covell.
Solar Wars was actually released in October 1999, so that page has its dates wrong.
SW's source and a dev diary are still viewable here:
http://www.chrismcovell.com/data/SolarWarsSource.zipI'm sure before I started dev, there were games (???) such as Mouser and others used as programming examples.
ccovell wrote:
Solar Wars was actually released in October 1999, so that page has its dates wrong.
Not anymore.
There were those example NES roms that came with Pasofami.
This doesn't answer the question, but Sack of Flour by Bob Rost (and co) was the first NES homebrew I played, though the one that convinced me really good stuff could be made was Dikki Painguin in TKO for the Third Reich (also by someone in Bob Rost's class).
https://www.youtube.com/watch?v=VjJ4UBPTpCs
This may depend on what contributes as homebrew. I think some of the unlicensed stuff on the FDS were originally developed by home hobbyists and later picked up by publishers such as Hacker, so these games may be considered borderline homebrew.
Also, there were people making stuff with Family Basic. I don't know other than self-satisfactory, whether they distributed these games to other people though. (I think the programmes could be recorded to tapes?)
So, unless you don't count the Famicom and focus only on the NES, and/or are more strict on what a homebrew is, it should be much earlier than that.
Great Hierophant wrote:
ccovell wrote:
Solar Wars was actually released in October 1999, so that page has its dates wrong.
Not anymore.
Thanks. The 2nd paragraph still has 2001, however, and you mistyped "Joey Parsell".
I'm fairly sure that while there was homebrews like "Munchie Attack" or "Box Boy 4k", Solar Wars was the first to look, feel and play like an actual game, with music, sound effects and the like. Although it's gameplay is, to be honest, quickly boring when playing alone.
I think NESSnake 2.0 was the first "full" homebrew that is not a tech demo with music, sound effects, graphcis that uses a significant portion of the console's abilities and that can be enjoyed completely alone.
Gilbert wrote:
This may depend on what contributes as homebrew. I think some of the unlicensed stuff on the FDS were originally developed by home hobbyists and later picked up by publishers such as Hacker, so these games may be considered borderline homebrew.
Also, there were people making stuff with Family Basic. I don't know other than self-satisfactory, whether they distributed these games to other people though. (I think the programmes could be recorded to tapes?)
Yeah I bet there where homebrew in the eighties by hobbyists, but with no internet to share them with they probably weren't very well known.
Family BASIC programs were shared by printing the source code in magazines or on recorded tapes (I don't know if there where any radio programs broadcasting Family BASIC tape data, but that is also a way), so that was the main homebrew community back then. IIRC the Pokemon creators started out programming with Family BASIC and picked apart a Famicom console in order to learn how it works, before they got recruited by Nintendo in the late eighties.
PC Engine had it's Develo BOX community in the ninties, code (BASIC and Assembly) was shared in magazines and the homebrewed executable programs, music and art came on CDs that came with the magazines.
ccovell wrote:
Great Hierophant wrote:
ccovell wrote:
Solar Wars was actually released in October 1999, so that page has its dates wrong.
Not anymore.
Thanks. The 2nd paragraph still has 2001, however, and you mistyped "Joey Parsell".
Apologies to Memblers, I fixed his name in two blog posts.
Thanks guys, this is the kind of information I was looking for.
Does "Super Maruo" count as homebrew? It was the first pornographic bootleg Famicom game, released a year after Super Mario Bros 1.
After an exhaustive search, I've identified about 200 completed NES homebrew games. I plan to feature about... maybe 40ish of them on my blog.
On an unrelated note, I thought of a way to make Mario Kart on the NES. It involves using less than 50% of the screen, CHR-RAM, much slower frame rate (maybe 15 fps), and raycasting. It would look crappy, but I think you could simulate mode7 style perspective.
If you want to do something like Mario Kart, make it more like Rad Racer along the lines of Sonic Drift for Game Gear.
tepples wrote:
If you want to do something like Mario Kart, make it more like Rad Racer along the lines of Sonic Drift for Game Gear.
That's been done before, so... not nearly as fun to make.
There have been a couple F-Zero/MarioKart-like homebrew games on the MSX and Megadrive/Gen that do a blocky sort of "raycasting":
https://www.youtube.com/watch?v=B_towiGufz4https://www.youtube.com/watch?v=7Nw3OL4-tw4https://www.youtube.com/watch?v=Yt_He0Ep02o
Quote:
On an unrelated note, I thought of a way to make Mario Kart on the NES. It involves using less than 50% of the screen, CHR-RAM, much slower frame rate (maybe 15 fps), and raycasting. It would look crappy, but I think you could simulate mode7 style perspective.
Would chr-ram page toggling be helpful in this regard?
If I were implementing Mario Kart on the NES (there goes the topic...), here's what I'd try first:
- Use 4x4 software pixels, so that all possible pattern combinations fit in a constant set of 256 tiles, eliminating the need for slow CHR-RAM manipulation;
- CHR bankswitching to separate the distant parallax layer from the road itself;
- Create look-up tables indicating the map coordinates of the contents of every on-screen pixel, relative to the player position, for all possible angles. That could end up being well over 100KB, but would eliminate the need for complex math: for each on-screen pixel, you'd add the relative coordinates to the player's position and use the result to read a color from the map, which may use tiling to save space;
- Objects/sprites would be drawn exactly like in a raycaster, possibly using logarithmic division and an arctangent look-up table to find the horizontal position of on-screen objects, and a multiplication is used to calculate their distances, and from that, their size.
tokumaru wrote:
Use 4x4 software pixels, so that all possible pattern combinations fit in a constant set of 256 tiles, eliminating the need for slow CHR-RAM manipulation.
I wonder if it would work to use 2x8 software pixels and use timed code to reset the scroll every 2 scanlines to increase resolution... I think we had discussed this idea, or a similar one for raycasting a while back.
If I took a stab at it, I would do polygons with XOR filling in a window centered in the screen. My thought is that a wireframe racer would be doable; adding XOR filling could just be a step beyond (it's not always that simple to add filling, but if we assume just a single flat road, it should be rather simple). I wouldn't try to have too much detail on the road itself to increase frame rate. Could be pretty decent, or pretty terrible.
Quote:
There have been a couple F-Zero/MarioKart-like homebrew games on the MSX and Megadrive/Gen that do a blocky sort of "raycasting":
https://www.youtube.com/watch?v=B_towiGufz4https://www.youtube.com/watch?v=7Nw3OL4-tw4https://www.youtube.com/watch?v=Yt_He0Ep02oSadly, this is what I had in mind, and it does look kind of bad.
I don't like the 4x4 pixel idea, but I suppose it would fill the screen, whereas my idea of having rendering off for 50% of the frame to write 240 tiles worth...3840 writes, over 4 frames is 960 writes per frame...is a bit crazy.
The third option is to prerender each frame of movement around the track and then have the camera move on rails. Toy Story Racer for Game Boy Color does this.
Celius wrote:
I wonder if it would work to use 2x8 software pixels and use timed code to reset the scroll every 2 scanlines to increase resolution... I think we had discussed this idea, or a similar one for raycasting a while back.
Yeah, that could probably be done to improve the resolution, but it may impact the performance quite a bit. Using a lower resolution not only makes things easier to display on the NES, but it also reduces the amount of calculations you have to do in order to render a scene and the amount of data that has to be transferred to VRAM. 4x4 software pixels would look like
the second video Chris posted, which is more than acceptable considering it's the NES doing it in software. Drawing interesting tracks using only 4 colors would be a challenge, though... more colors could be simulated with dithering, but then the combinations won't fit in 256 tiles anymore. Maybe the maps can be designed to not have more than 4 colors visible at a time, so the palette could change on the fly.
I feel like a higher frame rate is more important then resolution in a game like this, and since this is the NES we're talking about, there will have to be compromises.
dougeff wrote:
my idea of having rendering off for 50% of the frame to write 240 tiles worth...3840 writes, over 4 frames is 960 writes per frame...is a bit crazy.
The problem is not so much transferring that data to the PPU, but calculating those 4KB of data. You most likely won't get a playable frame rate if you need to generate and transfer a full pattern table for every game frame.
Quote:
The problem is not so much transferring that data to the PPU, but calculating those 4KB of data. You most likely won't get a playable frame rate if you need to generate and transfer a full pattern table for every game frame.
TG16/PCE could do it. Its processor is much faster.
Of course the "cool factor" is getting a worse system to do it.
PCE also has no restrictions to VRAM access, you can write stuff as fast as you can and anytime during the display. CPU is unable to use of all of the available VRAM bandwidth and there's no DMA device to do it either, similar problem to SMS/GG which have much more bandwidth than CPU can use up on its own. MD and SNES add DMA that can use up all the bandwidth available.
dougeff wrote:
TG16/PCE could do it. Its processor is much faster.
Well, I did program my own simplified version for the PCE.
https://www.youtube.com/watch?v=HEp7niIP4Qw
See, that proves my point. That looks beautiful. An NES version would look like Space Invaders by comparison.
tokumaru wrote:
I feel like a higher frame rate is more important then resolution in a game like this, and since this is the NES we're talking about, there will have to be compromises.
I would agree about frame rate being a higher priority. I would try to find a balance between resolution and complexity of textures to increase speed. I'm not a fan of complicated textures at low resolution anyway (that's why I think a lot of games on PS1 looked so bad). If you did some sort of polygon method, you could make basic shapes with solid colors, like the road with gray, grass with green, water with blue... Essentially if you can find where to draw the corners of the shapes on the screen, just connect those points with line drawing code and XOR fill.
The nice thing also about filling polygons with XOR filling is that it simplifies the line drawing code. You don't need to draw a line like this:
Code:
-------X
-------X
------X-
------X-
-----X--
-----X--
----X---
----X---
It only requires 1 pixel to be set per column of pixels:
Code:
-------X
--------
------X-
--------
-----X--
--------
----X---
--------
This speeds up line drawing tremendously. The more I think about this, the more I want to try this out and see how it looks!
Split the mario kart stuff?
feels like the discussion got derailed away already, nesdev style, but here's a compilation of Family BASIC games video(s):
https://www.youtube.com/watch?v=AD0DNX1RIkANo idea if they're from the time period or new stuff though
Those are (I believe) the type-in programs 1-30 from Family Basic Magazine.
There are also books like Family Basic ga Wakaru Hon that came with cassette tapes. UglyJoe dumped the tape data and printed out all the program listings from this book
here.
OK. I posted my big list of best and upcoming NES homebrews.
https://nesdoug.com/2017/10/31/a-list-o ... rew-games/Please (anyone) look it over and let me know if I made any errors or omissions or forgot a certain game. Thanks.
City Trouble wasn't made by MegaCat, just published by them. It was made by DRW. Expedition was also like that IIRC. edit: and Dushlan.
Dumb question.
Calima, you work for Mega Cats, right?
Indivisible is as complete as it will get.
It contains essentially 100% of the content from what it's based on. Two bosses, a still unfound trick, and like 200 animation frames. It's short, but it's
packed with content. At least give it a picture!
And a link.Edit: And ROM City Rampage should get some pictures too. It's actually pretty beautiful, even if there's not much to do. There's instructions for ripping it if you own Retro City Rampage in various places. Here's some gifs
Edit2: LJ65 by Tepples is super good, even if it's no longer distributed by him. I might be biased just because it's got Tetris Grand Master Series gameplay.
Blade Buster!
Hmm. I might just make a second post, there's a lot of good stuff around.
I think ALL the games on that list deserves a picture!
Also, I'd like to see the list being a lot more structured. As a blog post it gets out of hand really easily. I'm glad to see it mostly populated with genuinely interesting looking games, though. There is a lot of pointless fluff in the homebrew scene that easily ends up flooding lists like this if you have a truly completionist approach to it.
Kasumi wrote:
I might be biased just because it's got Tetris Grand Master Series gameplay.
Not a bias. TGM is objectively incredible.
Kasumi, thanks for the update, I will put a picture in.
I respect tepple's decision to not distribute LJ65.
According to my notes, it was included on the MGC 2011 cartridge, if there is anyone on the internet who wants a copy of it (it's rare).
dougeff wrote:
Calima, you work for Mega Cats, right?
Yes.
dougeff wrote:
OK. I posted my big list of best and upcoming NES homebrews.
https://nesdoug.com/2017/10/31/a-list-o ... rew-games/Please (anyone) look it over and let me know if I made any errors or omissions or forgot a certain game. Thanks.
Oh, you forgot about me and The Banketh
Diskover, It's possible that I have underestimated Banketh, since I had only played an early DEMO. It looks (Youtube videos) bigger than I remember. Maybe I'll add it on.
OK, I added some pictures and moved some things around (Diskover).
Sorry, Kasumi, I haven't had time to play your game, which explains my ignorance of it. Maybe I will write more about it later.
dougeff wrote:
Diskover, It's possible that I have underestimated Banketh, since I had only played an early DEMO. It looks (Youtube videos) bigger than I remember. Maybe I'll add it on.
Thanks for including it.
The game is finished. It has 5 levels, introduction, end, etc ... I even manufactured five units.
I wanted to do another crowdfunding again, but I think I'll wait next year due to the excess of work that I currently have
dougeff wrote:
The Cat Quest project seems to have morphed into a game called Transamnia
Heh! That's not far off from the truth, actually! Transamnia's code was rewritten from the ground up, though.
Five months after cancelling Cat Quest, a friend of mine told me: "Fuck those guys, you should make Cat Quest into a porn game!"
...and so, Transamnia's name for the first week of development was:
Once a story was written, and the hero was designed, the Cat Quest girl was replaced. She will appear as an NPC, though!
It's kind of funny that you picked that particular image, since it was a recreation of one of the overworld screens from Cat Quest!
I prefer this mountain scene, using the cave tileset in the overworld, myself:
I wouldn't say that Cat Quest will never be released, it will be! Just not on the NES!
I've been writing a demake for the Atari 2600 (inferior hardware):
...and an enhanced port of the original NES game, to the Commodore 64 (superior hardware):
Cotton & Candy is currently 90% complete, the only things missing are the final world, and the game's soundtrack.
Alp wrote:
Commodore 64 (superior hardware)
Really? The images you posted are nice, but they don't look better than the amazing NES graphics you posted before. It's probably because of the wide pixels of the C64... I can't really consider that "superior" when compared to the NES.
Commodore 64's hardware is definitely neither supperior nor inferior, but was designed with a very different philosophy.
- Graphics have less colours, but they're not fully saturated
- Horizontal resolution is typically sacrified for more colours -> non square pixel aspect ration
- There's much, much more RAM
- CPU is about twice slower (as the bus is shared with the video chip).
- Less sound channels (3 instead of 4), but those are much more powerful than NES' sound channels
- If more than 8 sprites are needed, software multiplexing must be used, but sprites are much bigger and usually metasprites aren't required.
- Typically jostick with single button are used, which is inferior to NES' joypad, but the keyboard is available if more buttons are needed.
So while the C64 is "mostly" inferior to the NES in some points (sound, RAM) it shines.
Bregalad wrote:
So while the C64 is "mostly" inferior to the NES in some points (sound, RAM) it shines.
Well, RAM was a necessity because you cannot run a game directly from disk, so all of its program code has to go into RAM first.
So, it's not
really that much of an advantage over the NES, is it?
Besides, did anybody ever actually run out of RAM space on the NES? You have 2048 bytes (minus 256 for sprites). This should be more than enough for every game.
I'm working on a full-blown "Zelda"-like adventure game and my only worries regarding RAM is whether I can manage to put all variables
in zeropage (except for some huge arrays). But I think I will never ever run out of regular RAM space, even if we ignore the additional 8 KB of battery RAM.
So, the only real advantage of the C64 over the NES seems to be the sound chip.
DRW wrote:
Well, RAM was a necessity because you cannot run a game directly from disk, so all of its program code has to go into RAM first.
So, it's not really that much of an advantage over the NES, is it?
It's hard to pick a winner here... It's true that 64KB of RAM is a lot, and even when most of it is used for code and data, significantly more than 2KB should still be left for general use. On the other hand, since the NES runs games directly from ROM, you can have almost instant access to more than 64KB of code and data through bankswitching, and cartridges can easily pack extra RAM to compensate for those 2KB. However, AFAIK, the Commodore 64 can also use cartridges, in which case it could probably have these advantages too.
Quote:
Besides, did anybody ever actually run out of RAM space on the NES? You have 2048 bytes (minus 256 for sprites). This should be more than enough for every game.
That's... very optimistic of you. We know for sure that several developers back in the day felt like they needed extra RAM on the cartridge, not only the ones that needed battery backup. Sometimes the extra RAM may not be necessary, but it certainly makes things easier/faster. It's definitely easier to have unrestricted access to an entire level map in RAM than decode it on the fly from ROM and "patch" any changes they might have suffered in real-time. 2048 bytes is far from excessive if we're talking about 16-bit-type games. Varied enemies with complex behavior in large levels can quickly consume a lot of RAM. I particularly find it very fun to try and map all the functionality of 16-bit games to the constraints of the NES, and IMO, most of the time it can indeed be done, you just end up with a more complex program than if you had all the space in the world.
Quote:
I'm working on a full-blown "Zelda"-like adventure game
The original Zelda is a pretty early NES game, and the screen-by-screen gameplay is definitely a RAM saver. In my experience, the biggest RAM killers are level maps and objects, and neither of those are particularly troublesome if the map in question is only 1 screen large and all the objects are the ones inside it.
DRW wrote:
Besides, did anybody ever actually run out of RAM space on the NES? You have 2048 bytes (minus 256 for sprites). This should be more than enough for every game.
Good luck doing a finely destructible and backtrackable map the size of a
Super Mario Bros. 3 level without extra work RAM in the Game Pak. For instance,
an article by the programmers of M.C. Kids explains that without work RAM, the game might have needed smaller levels, possibly coarser destructibility, and certainly more programming complexity. Something like
SimCity would be right out, as the prototype appears to need more than 32K of RAM: some for work RAM and some for save. The game's map alone is 120x100 spaces.
tepples wrote:
Good luck doing a finely destructible and backtrackable map the size of a Super Mario Bros. 3 level without extra work RAM in the Game Pak.
Do you really need the entire map to be destructible, though? Most games don't. If you have up to 1.024 blocks (that's over 4 full screens worth of 16x16-pixel breakable blocks) you can save their existence state in 128 bytes, 1 bit per block. That does increase the complexity of the program though, because you have to treat breakable blocks as objects, and patch the level map cache accordingly, but it's doable. One advantage of treating breakable blocks as objects is that you can have complex backgrounds behind them, since the level maps are "clean" of breakable stuff.
Well. Simcity. Just Simcity. I bet the mandatory extra RAM added to the manufacture cost was one main reason the NES/Famicom of it got canceled.
DRW wrote:
So, the only real advantage of the C64 over the NES seems to be the sound chip.
And even then, we could agree that 4 channels is better than 3, no matter how featured they are, since it allows for significantly more harmonic/rythm without resorting to annoying arpeggios. Also the individual C64 channels officially doesn't have direct volume control (but with a trick they can have it).
If you max out (and you're likely to), 4 is definitely more than 3. But at the same time considering the SID chip was much more flexible on what each channel could do (change roles, have a filter), you could make an interesting, varied and illustrative soundtrack in ways you can't on the nes. You're more likely to use two channels in order to sound like one more complex channel here and there on the NES, too.
One example of the SID being more "Illustrative" would be comparing the "scream" effects in the intro song to
ghouls n ghosts (c64) to Shadax' scream in Solstice (NES), both by the same artist (uh, couldn't find an example of someone losing a life on youtube... oh well).
Home computers costed more than home consoles though, so they could afford to have more RAM. Or is there are reason why computers needs lots of RAM besides for disk loading (FDS only has 32 kB PRG-RAM and 8 kB CHR-RAM)? I'd think (arcade) games would be the most hardware demanding programs for a computer.
Nintendo wanted to make a home version of their arcade machines but that didn't cost as much so I guess they needed to cut down on things like RAM and colours.
Besides the disk/tape loading, I guess the answer is BASIC-dependent software and GEOS (optional but popular).
Plus it's not just games. A fullblown graphics editor etc etc might eat more "work" RAM than your average game.
Oh, and SID having proper hardware accelerated ADSR envelopes both helps the composer out a lot and would burden any music driver less.
DRW wrote:
Besides, did anybody ever actually run out of RAM space on the NES? You have 2048 bytes (minus 256 for sprites). This should be more than enough for every game.
All the time. Sprites take 256 bytes. ZP takes 256 bytes. Stack + famitone take 256 bytes. Then you should leave space for cc65's stack, let's say 64 bytes. Down to 1216 bytes before any of your own things.
cc65's stack.
If you program like me, with all globals, no recursion, and only occasionally passing more than 1 variable to functions... (Like my jammin honey game)...
I have only 16 bytes reserved for the c stack. It gets used mostly for the metasprite function that Shiru wrote.
However.
My Vigilante Ninja 2 game completely ran out of RAM space. There was only a few dozen left on the 2 pages used for level data, but due to a bug, this was unusable, because if you jumped into the top of the screen it would occasionally check those bytes for collision, even though they aren't properly level data.
calima wrote:
Sprites take 256 bytes. ZP takes 256 bytes. Stack + famitone take 256 bytes. Then you should leave space for cc65's stack, let's say 64 bytes. Down to 1216 bytes before any of your own things.
I'd add about 128 bytes for a video memory transfer buffer. But I'd dispute the "ZP", as a lot of "your own things" can go there.
I normally use 212 or so bytes of page 1 as my VRAM transfer buffer, the rest goes to the stack. I may use more than that in programs with less traditional graphics engines (e.g. a raycaster).
ZP is indeed mostly for our own stuff... I try to put all my variables there, while arrays and a few of the less frequently used variables occupying the remaining pages.
I have variables used for my sound routine on it's own dedicated page because they are too many to fit in ZP. Other variables are on ZP though, and I have yet to run out of ZP. First part of ZP is dedicated to general purpose variables and pointers. I don't think a lot of stack is used either so I reserve more than half of page 1 for VRAM buffering. This leaves 4 pages for arrays and anything else. I planned to use page 7 as a high score table and I skip clearing it if a RESET is detected.
I'm not particularly fond of the background, but those explosions look great for an NES!
DRW wrote:
did anybody ever actually run out of RAM space on the NES? You have 2048 bytes
On the SNES, my sprite table alone takes 6KB.
About the C64 vs the NES, if the C64 didn't have double-wide pixels, I'd say it's the indisputable winner graphically. Add one more sound channel, and it's the same deal with audio. I think it's fair to say the C64 is weaker than the NES, but it gives it a run for its money, because frankly, I think it's just designed better. Same story with the SNES vs Genesis; with how much shit they piled on the SNES, having twice the ram and two video processors, there shouldn't even be a debate as to which one is better.