Too bad the artwork is bad.
Anyone got the rom of that game ? seems cool ... even the modern 8/16 bit GFX
I'm not very fond of this "pseudo-retro modern pixel art" style, too bad they're going with that for an actual SNES game.
funny to see that is doable on real retro console ...
These graphics seem just plain lazy to me.
It does say in the article that the guys who're doing this are not artists, which must be why they're mimicking this type of sad excuse for pixel art that's so common these days.
I wish I knew what the whole "SNES has no documentation" thing is about. Nobody is going to write a tutorial explaining every single hardware aspect in great detail. That's why we have separate tutorials for 65816 ASM, memory maps, PPU, SPC700, ect.
wow you guys, nothing but complainers
(except lint).
How about a little bit of encouraging words, they actually help build community.
What if they read your comments, would they then want to hang out here?
Note that article's from 2014. No apparent updates on Twitter since, nor do they seem to have any non-social-media presence.
Well, I'm glad they figured out how to program the SNES. I still wonder exactly what is missing in SNES documentation.
Well, it's not like we have much to go on... just a single screenshot and a generic interview. Having a new homebrew game is great, but that doesn't mean we have to kiss ass by default (there are tons of bad homebrew games!). I'm not being an asshole either, I just think they made a bad choice with the artistic direction, going for a bland generic style instead of something more remarkable. It doesn't look bad, just... bleh. The game might still be really good despite this, we'll see.
Myask wrote:
Note that article's from 2014. No apparent updates on Twitter since, nor do they seem to have any non-social-media presence.
Yeah, I don't think they're working on this anymore. Development ceased after a few months.
Here's their Twitter by the way:
https://twitter.com/namespacegamesI guess the team is one guy and one girl. The pictures in the article had me thinking it was two guys.
Fair enough. Let me revise my previous comment.
The graphics serve their purpose, but you'd probably want to polish them before a release. We don't have live photage from what i can tell, but for instance, i guess the trees have a light/shadow effect to show that they're platforms to reach the cliffs in what i think is a non-moving single screen. That's fair enough. But since they are the only elements that have lightening/shadow applied to them, they pop out more than anything, including the characters, which are shown in front but doesn't look like it in comparison. If the foliage has highlights, why doesn't the grass? Light/shadows, if used, should be applied globally as far as possible.
I could also be wrong about the trees, in which case their popping is misleading. Maybe the cliffs are meant as blockades which you can't overcome.
I think the background as a whole needs to follow a ruleset that takes gameplay into concideration. Devs, artists, and designers need to remember that a first time player don't know what's what. Solids should be more popping than semisolids/jumpthroughs, and semisolids should be more popping than pure immaterial background.
Artistically, i have a personal inclination partly against (for the lack of thinking up a better term) retrofakeing, but that isn't universal and it certainly doesn't mean it can't be done in a pleasing way (Shovel Knight looked and felt great). An example i hope can help illustrate this is the common difference i've experienced (and am assuming others have experienced) between actual video game music and many chiptune tracks. In SMB1, the music reflects the mood of the stage. Underground feels underground, the creepy castle music puts you on the edge of the chair, especially the first time, and so on. Much chiptunes, especially stuff i heard people play live in the 00's, had basically one expression: "i want to represent a general sense of video games without reflecting the the specific content of an actual or imagined video game". So for the most part i heard LSDJ live shows with super-cheery, gallopy, childhood-encopassing blippetyblop, with the occational heavy metal-like variation. This is not truly representative for video game music, however reminding of dominant strokes.
This goes for a lot of the 'indie' content seen on the wii u online store. Instead of presenting original aesthetics that are tailored to the intended experience, some of these devhouses think it's enough to make it look like what the general public may think is a retro game, maybe because of lack of devtime, maybe because of lack of knowledge, will, or confidence. Hobbyists have the relative luxury to avoid this trap by trading personal time for getting more experience and knowledge and confidence. I think time is really the key here. To dare to avoid saying 'good enough' too early. Let it grow.
They have a start, and it seems they have a vision (being from Nottingham, doing a robin hood game, on a platform they like). I think it needs work, and i think the feeling of reward is more probable the more labour you put into reflecting why things should look, sound, feel in a certain way.
Judging from the notion of 'lack of documentation', they may be more or less isolated from other homebrewing communities and their repositories, in which case i think it's safe to say that they could benefit a lot from being introduced and getting references on what other peers do for a hobby, more so than opinions like the one i wrote.
It's disappointing that another group of homebrews got stuck.
I'm really not aware of any other SNES homebrewers getting stuck, or even any SNES homebrewers who have gotten to the point where they're really showing off their game, aside from you maybe. You seem to have made considerable progress. I've restarted more times than I'd like to admit, and I don't see myself going anywhere soon. I think I might try a basic vram system first, where 8x8's and 16x16's are being used and objects use slots of only 16x16 instead of 32x32. I still plan on implementing a linked list and everything for redundancy, because I don't actually want to use all 16KB. What I'm planning on doing now is a lot less sprite heavy than a run and gun like I was originally planning. (I came to the realization that that's a hell of a lot of fancy programming and especially artwork to be drawn for just me.)
SNES homebrewers, i take it SNES graphics take more effort to complete?
Also, everyone seems to be writing asm for SNES. I haven't looked in depth, is there really no decent C toolchain and a library for the native functionality?
Gen has good docs and good tools, NES has good docs and mediocre tools, GBA has terrible docs and average tools. Is SNES at "bad docs and no/bad tools"?
well, asm seems simpler for snes than nes. you can branch always without double checking conditions, for one thing. With some of the naughtyness of 6502 asm improved, one could argue a higher level is a little less warranted. Comparing whith x86 asm where you have JZ and other jump-on-conditions and all sorts of shortcutting luxuries which is very high level-like.
There's at least one C toolchain:
http://www.portabledev.com/wiki/doku.php?id=startBut I imagine most developers use assembly for the same reason graphics take a long time to make - the SNES is capable of a lot, and they want their games to be
good. C can be compiled into serviceable 68000 code, but I'm given to understand it's a poor match for 65xx. Which is why NES programmers who care about performance code in assembly too...
I find SNES documentation is adequate if you know where to look:
http://wiki.superfamicom.org/snes/show/HomePagehttp://problemkaputt.de/fullsnes.htm (or
http://problemkaputt.de/fullsnes.txt for a more recent version)
http://wiki.nesdev.com/w/images/7/76/Programmanual.pdfhttp://fdwr.tripod.com/docs/65c816.txtNot to mention the actual official SNES manuals (which are admittedly not great)...
But then I haven't ever programmed any other game machines...
WheelInventor wrote:
SNES homebrewers, i take it SNES graphics take more effort to complete?
Relative to NES graphics? Definitely. 4x the colors to worry about and larger sprites and more BG layers will do that.
93143 wrote:
Didn't know about this one -- it even has the T-state breakdowns for all addressing modes. Beautiful!
calima wrote:
is there really no decent C toolchain and a library for the native functionality?
I'm quoting Shiru from a recent NintendoAge post...
Quote:
There is 2-3 C compilers (tcc-816, snesc, and the elusive WDCTools), there is a strong-ish library (PVSnesLib), there is all-in-one game-targeted music editor (SNESGSS),
Link to quote...
http://nintendoage.com/forum/messagevie ... did=162880
koitsu wrote:
93143 wrote:
Didn't know about this one -- it even has the T-state breakdowns for all addressing modes. Beautiful!
It looks like a transcription from a datasheet. But I'll give it to you, that sure is quite complete.
EDIT: "looks like" more like it
is:
Quote:
G65SC802 / G65SC816 Data Sheets
Sik wrote:
EDIT: "looks like" more like it
is:
Quote:
G65SC802 / G65SC816 Data Sheets
Yeah, the data sheet it's transcribed from is for the 65802 and 65816 CPUs that CMD/GTE made. I think it's possible to find data sheets for the CMD G65SC816P?
dougeff wrote:
I'm quoting Shiru from a recent NintendoAge post...
Quote:
There is 2-3 C compilers (tcc-816, snesc, and the elusive WDCTools), there is a strong-ish library (PVSnesLib), there is all-in-one game-targeted music editor (SNESGSS),
I'm afraid that's a "no, there is no decent toolchain". WDC's is proprietary, Windows-only and $$$, snesc is even less C compliant than cc65, and tcc code quality is just bad even on x86.
Espozo wrote:
WheelInventor wrote:
SNES homebrewers, i take it SNES graphics take more effort to complete?
Relative to NES graphics? Definitely. 4x the colors to worry about and larger sprites and more BG layers will do that.
One thing that I've never understood is that people who make a homebrew snes game, you dont have to use all the colors available. You could make it look like an NES game if you wanted to or an atari 2600 game.
So graphics wise an snes game doesn't have to be superior to that of older consoles.
Erockbrox wrote:
One thing that I've never understood is that people who make a homebrew snes game, you dont have to use all the colors available. You could make it look like an NES game if you wanted to or an atari 2600 game.
So graphics wise an snes game doesn't have to be superior to that of older consoles.
The response will be overwhelmingly negative, "why did you bother, that's clearly a NES game". Kind of like the faux-8bit graphics on PC, except without hipsters supporting them.
Erockbrox wrote:
Espozo wrote:
WheelInventor wrote:
SNES homebrewers, i take it SNES graphics take more effort to complete?
Relative to NES graphics? Definitely. 4x the colors to worry about and larger sprites and more BG layers will do that.
One thing that I've never understood is that people who make a homebrew snes game, you dont have to use all the colors available. You could make it look like an NES game if you wanted to or an atari 2600 game.
So graphics wise an snes game doesn't have to be superior to that of older consoles.
I actually had an idea that relied on such low color counts so that I could use all eight palettes for color variations of the player characters, then use the remaining colors in the sprite palette for something else.
calima wrote:
The response will be overwhelmingly negative, "why did you bother, that's clearly a NES game". Kind of like the faux-8bit graphics on PC, except without hipsters supporting them.
Yeah, if my experience with homebrew is anything to go by, people don't just want you to make the game look good, they want you to make a game that goes beyond whatever the best licensed games ever did. And then later people wonder why I insist in comparing my stuff against the classics, that's the
bare minimum bar to aim for if you don't want to get swarmed down in everybody and their dog throwing endless suggestions at you =/
Quote:
Yeah, if my experience with homebrew is anything to go by, people don't just want you to make the game look good, they want you to make a game that goes beyond whatever the best licensed games ever did. And then later people wonder why I insist in comparing my stuff against the classics, that's the bare minimum bar to aim for if you don't want to get swarmed down in everybody and their dog throwing endless suggestions at you =/
Report this post
From my understanding I would think that the expectation for homebrew games would be quite low and I wouldn't expect them to be as high quality as the officially licensed games of the era. Why? Because back then there were companies and teams of people working on these games and they had money to put into the game along with it being their full time job.
Now its mainly for hobbyist. When someone does a homebrew now its not like there are sitting on a huge lump of cash with an entire team of people working around the clock on it. There are some exceptions to this and it does vary from platform to platform.
Sure a single person can make an atari 2600 game now that rivals that of the best games from its time, but a single person can't do the same thing with like an SNES game.
I think doing an snes game in an nes style would be cool. It would be like a glorified nes game. If you just watched a playthrough video of it, you might actually think its for the nes.
Even if a homebrew Super NES game doesn't graphically surpass the best looking commercial games on the platform, players will still want it to look no worse than launch titles such as Super Mario World, whose graphics can be seen as a transitional phase between NES and Super NES.
"The PPU is more complex. Why bother?"
"The APU has a separate ISA, supported natively* only by assemblers with a greater reputation for bugs, and communication between it and the main CPU is fiddly. Nor are there a wide variety of pre-made music engines like FamiTone, GGSound, and Pently. Why bother?"
* Yes, I'm aware of a ca65 macro pack that blargg and I worked on years ago that adds support for SPC700 with both Sony and 65C02 syntax.
The weird thing about graphics is that you can be doing stuff that is impressive for an SNES game, but if you keep the color count low, people will think you were lazy.
Or you could stop making up imaginary arbitrary reasons the public will hate your game, and just make something you think is good.
rainwarrior wrote:
Or you could stop making up imaginary arbitrary reasons the public will hate your game, and just make something you think is good.
Haha, for people with high standards that is way worse. Making a game
I'd find good would require me around 100 years or so
(need to become a good artist, a good composer, master a few dozen instruments, learn several languages, and gain enough money to hire people for full VA and several hours of cutscenes)
Then you may need to seek funding in order to acquire the right talent.
- Write a design document. At first, it sets the direction for the game; later, it serves as a living standard to document its style.
- Produce a playable proof of concept with very basic art and music. For Portal, the proof of concept was titled Narbacular Drop.
- Crowdfund. Include only one language with subbed dialogue in the basic goal, and include translations and voice acting in a stretch goal.
- Hire artists, musicians, sub translators, and voice actors.
- Make your game.
calima wrote:
gain enough money to hire people for full VA and several hours of cutscenes)
You and I have very different opinions about what constitutes a good game!
rainwarrior wrote:
Or you could stop making up imaginary arbitrary reasons the public will hate your game, and just make something you think is good.
In full agreement with this.
If your heart is set on accomplishing something, do it! There will always be people (members of general public) who dislike a game for whatever reasons (legitimate, trivial, doesn't matter) -- in the same way there are people who dislike commercial high-end games for whatever reasons (I know lots of people who loathe several classics that, for me, are awe-inducing). You can't make everyone happy. Just take the criticism with a grain of salt (or to heart if you feel it has merit) and do what makes you happy.
tokumaru wrote:
calima wrote:
gain enough money to hire people for full VA and several hours of cutscenes)
You and I have very different opinions about what constitutes a good game!
Espozo wrote:
:lol:
I didn't mean to sound rude... Different people like different types of games, and that's OK. I actually do like cutscenes (VA is really hard to get right, though... most games end up sounding very silly), but when you have hours worth of them the game starts feeling more like a movie than a game.
Plus even if you devote half of a 32 Mbit ROM to BRR voice samples played at 8 kHz (about telephone quality), you get 466 seconds of voice.
That is, unless you detect and exploit micro-loops in the voice data. (Lord Nightmare has been pestering me off and on to make an encoder for these micro-loops, but I'm busy with other (paid) projects.) But even that won't get you past, say, an hour of voice in 2 MiB.
calima wrote:
Making a game I'd find good would require me around 100 years or so
I'm feeling a bit of detachment from the issue at hand, in that my current project (being a port) doesn't require me to be good at art, music, or game design. All I need is knowledge and technical skill in graphics, digital audio, and programming, coupled with enough problem-solving ability to make everything work.
And it's
still taking forever. This "free time" thing ain't what it used to be... and let's just say that with sufficient attention to detail it's possible to substitute time for skill...
Now, I
could technically have proven my point with much simpler graphics and sound, or even no sound at all (it's pretty well known that the SNES doesn't take much of a penalty for basic audio). The essence of the game doesn't lie in the fancy sidebar or the rotating/perspective backgrounds or the multilayer transparency or the high-fidelity music and sound effects. It's a bullet hell game. 2bpp bullets with a basic HUD is all I needed. But I
wanted more. I wanted to replicate the presentation of the original as closely as possible, not just the gameplay, even (or especially) if it required me to push the envelope in every direction at once.
Now, my concept for an RPG -
that, simply put, I expect to never bother with. Maybe if radical life extension becomes available and I can get on board for millennia of extra time...
...
I guess my point is the same as calima's - it's not just the expected reaction from players that motivates SNES homebrewers to try to fully utilize the available resources. For the most part, the developers I'm aware of seem to want to push the limits of the hardware in some way, not just implement a brilliant gameplay idea in whatever audiovisual style they feel would be deemed acceptable, or produce some kind of faux-retro game on an actual classic console...
tepples wrote:
That is, unless you detect and exploit micro-loops in the voice data.
That sounds a bit like something I've been trying to do with instrument samples, to fit long dynamic sustains or decays into a small amount of ARAM. I'm not sure whether I got the idea from psycopathicteen or KungFuFurby, or both, but it seems to kinda work.
My problem is that I'm using manual detection...
tepples wrote:
That is, unless you detect and exploit micro-loops in the voice data. (Lord Nightmare has been pestering me off and on to make an encoder for these micro-loops, but I'm busy with other (paid) projects.) But even that won't get you past, say, an hour of voice in 2 MiB.
Unless you're making a full blown RPG, that may be enough though. Your alternatives are:
- Write the script intentionally trying to reuse parts of phrases (how odd it turns out depends on how clever you can get).
- Figure out how to make speech synthesis that sounds good =P
I still don't quite get the big aversion to having large carts.
Well, for one, you need to use the rest of the space for graphics and such, and something of this scale is probably going to be using a lot of them.
I suppose that if you really insist you could just make a cartridge that has all the heavy stuff in a SD card =P
CF has the advantage that it's already parallel and operates at 5V, which might (maybe) be enough to offset its cost premium.
(SD/eMMC will at least require voltage generation, translation, and benefits from external parallel-to-serial conversion)
lidnariq wrote:
CF has the advantage that it's already parallel and operates at 5V, which might (maybe) be enough to offset its cost premium.
And the disadvantage that it's not really used anymore.
That only matters if you expect the end user to need to add a CF card, not for manufacture. I'm pretty certain we're not talking about flashcarts.
Is there a surface-mount flash memory with a parallel ATA interface that you had in mind? Because if surface-mount mass storage is all eMMC nowadays, you'd need to buy a CF card and mount it in the cartridge. Though I imagine eMMC could be made to work as a DSP source with a CPLD acting as a buffer, with the actual chip clocked by master clock.
But either way, loading most code and data from storage would take up a lot of WRAM in the $7E2000-$7FFFFF area, unless the cart has extra RAM (as on the FDS or SNES CD system cart). And you'd still need either a ROM or an MCU to boot the thing.
tepples wrote:
Is there a surface-mount flash memory with a parallel ATA interface that you had in mind?
Disassemble CF card, desolder connector, solder resulting two-sided board in. Needs a funny footprint, but whatever.
Quote:
Because if surface-mount mass storage is all eMMC nowadays, you'd need to buy a CF card and mount it in the cartridge. Though I imagine eMMC could be made to work as a DSP source with a CPLD acting as a buffer, with the actual chip clocked by master clock.
eMMC only comes in fine pitch BGA, which is about as hostile to DIY as possible while still technically being doable.
You're going to have a connector of some sort to use bulk commodity memory, or else you're going to be using a known-good-die NAND flash, and as I said, you're going to need voltage translation unless you're using CF.
You can still buy new CF. The prices are not higher enough than SD to make it the wrong choice unless you
already have to add voltage translation and programmable logic. Instances where the end user has to buy CF is explicitly out of scope.
tepples wrote:
But either way, loading most code and data from storage would take up a lot of WRAM in the $7E2000-$7FFFFF area, unless the cart has extra RAM (as on the FDS or SNES CD system cart). And you'd still need either a ROM or an MCU to boot the thing.
Why are you talking about using flash
instead of ROM? I just assumed you were all discussing MSU1. I see no reason to have code or random-access data behind a bulk storage interface when you can have as much as 95 Mbits directly accessible to the CPU without even getting creative...
For the same reason some NES homebrew games have switched from battery-backed SRAM to a flash memory that can be programmed in circuit: one memory is cheaper than two.
Yeah, but as you pointed out it's a giant pain to have to load everything into WRAM before using it, and you need something to boot from anyway. Personally I'd eat the cost and go with the more flexible option of putting bulk data behind the MSU1 and code and random-access data in a ROM.
If you can come up with an interface that maps part of the flash chip to the A bus as ROM (and possibly RAM), while preserving the streaming functionality for the rest of it (or allowing software-controlled mapping), without spending more on glue logic than you would have on memory, that's cool too...
tepples wrote:
For the same reason some NES homebrew games have switched from battery-backed SRAM to a flash memory that can be programmed in circuit: one memory is cheaper than two.
Wasn't it because nobody likes the risk of the battery dying? =x
And yeah, my suggestion was to use the SD card for streaming the heavy stuff (in this case voice acting, but you could add FMV or other stuff like too) and the ROM for the usual game stuff (all code, the graphics you use regularly, etc.) And yes I know it's more expensive. Doing something that doesn't fit in the ROM is already expensive anyway =P