It is currently Tue Oct 24, 2017 4:34 am

All times are UTC - 7 hours



Forum rules


Related:



Post new topic Reply to topic  [ 291 posts ]  Go to page Previous  1 ... 3, 4, 5, 6, 7, 8, 9 ... 20  Next
Author Message
PostPosted: Mon Apr 21, 2014 5:43 am 
Offline

Joined: Tue Aug 15, 2006 5:23 am
Posts: 172
Location: Spain
psycopathicteen wrote:
Okay, I'm finished with the snes initiation code.


Thanks for your effort. I have just taken a look at it and I would have initialized $2100 with zero brightness, since you probably will show your first image on screen coming from a fade-out (black to the image).

Somebody know if there have ever been a commercial game's source code leaked to the internet? I've read about how programmers did the game in those times, such as Secret of Evermore and its customized scripting system; I would like to know the inner of SNES games: how they manage events, the command scripts, drawing into VRAM, sprite creation, movement and collision, and so on.

So far, I reverse-ingeneered some games (Final Fantasy 6, Romancing Saga 3 and Treasure Hunter G) and all of them are different:
* FF6 uses different NMI routines for different kind of scenes (intro, worldmap and menus, at least, but I suppose they are different from NMI used in battles and cities), and the intro is built through a event queue (a RAM array) filled with routines that draw the Magitek armors, print the credits, set the HDMAs and manage the timing. The command script for the game is separated from the text script.

* RS3 uses different NMI routines for maps, battles, military battles and menus, pretty much like FF6. I didn't make through the event system, although I disassembled all the text scripting engine. The command script is not fully separated from the text script: the text script engine checks and writes some flags and variables to trigger some events or print different texts, so the text is mixed with those commands.

* THG is pretty tough, since it uses a mix between the previous: in each scene, the command script dictates which graphic chunk is to be decompressed, which VRAM address it has to be sent to, the CGRAM palette and some (so far) undefined things; there are 48 different commands. One of the commands points to a bunch of events that may occur in the current scene, and they are stored in a RAM array; there are 14 commands that defines each event. Finally, each scene has a bunch of dialogue pointers which are treated different from the events and which have their own 208 commands: variable and flag checking, text printing... pretty much like RS3. And my personal opinion is that the game was programmed in C, considering some data which looks like structs, the routine calling system, and so on...


Top
 Profile  
 
PostPosted: Mon Apr 21, 2014 6:12 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19122
Location: NE Indiana, USA (NTSC)
magno wrote:
Somebody know if there have ever been a commercial game's source code leaked to the internet?

Someone disassembled Super Mario Bros. for NES, and I'm told the code changes from NES to Super Mario All-Stars weren't huge. There are also some M.C. Kids post-mortem documents; they're not source code but they still have implementation details. It also depends on how you define "commercial": some open-source homebrew games have been sold on the Action 53 multicart.


Top
 Profile  
 
PostPosted: Mon Apr 21, 2014 12:10 pm 
Offline
User avatar

Joined: Wed Dec 06, 2006 8:18 pm
Posts: 2801
I think B.O.B. for SNES's source code was leaked. I seem to recall seeing it at some point. It should be out there somewhere.


Top
 Profile  
 
PostPosted: Mon Jun 30, 2014 10:19 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19122
Location: NE Indiana, USA (NTSC)
byuu wrote:
Current debugger for phoenix is called loki: http://byuu.org/images/loki/loki-20140130.png

As nice as GUIs are, they're just too much of a hassle. So this one is terminal-based. Haven't posted a downloadable version yet, still adding features.

Has the "loki" debugger stabilized over the past few months? I'm getting feature requests for more colors in one of my NES games, and I figured a port to the Super NES would be easier than putting MMC5 ExGrafix on a CPLD.


Top
 Profile  
 
PostPosted: Wed Dec 02, 2015 9:22 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19122
Location: NE Indiana, USA (NTSC)
With a port of one of my games to Super NES tying for second in a recent poll, I felt the need to summarize the status of solutions to these problems, nearly two years on:

  1. Separate SPC700 syntax and buggy WLA: Solved with blargg's macro pack.
  2. Finding samples: Permissively licensed sound fonts are believed to exist, but I must have missed where. (?)
  3. Making use of all 15 colors: Start with three lightnesses (normal, highlight, and shadow) of up to five of your character's colors, and stop fudging with similar colors (like SMB3 does with black overalls) or overlapping sprites (hi Mega Man). Draw surfaces pointing toward light lighter and surfaces pointing away from light darker.
  4. Finding something to put into BG2 and BG3: (?)
  5. Minimum size: A 1 Mbit UNROM or SxROM game will likely nearly double to almost 2 Mbit due to increased graphics color depth, SPC700 samples, and additional graphics for BG2 and BG3. That and you can improve the main character's animation or turn palette swapped enemies into distinct designs. For an NROM-scale game, there's no shame in padding the binary with $FF.
  6. Testing: Use bsnes-plus or no$sns (which works in Wine) for debugging and a Super EverDrive or SNES PowerPak for hardware verification. But with the DMA glitch, we may need to compile a list of people willing to test on 1/1/1 consoles. (?)
  7. Hello world: I've since made a Super NES version of my ca65 project template, and mic_ has listed others.
  8. C compiler: Answer is similar to NES. Try tcc-65816 for mostly turn-based games, assembly for real-time games.

What remains are links to sample packs, something to put in the parallax backgrounds, and DMA glitch testing. Are there any other excuses for plenty of NES homebrew releases and so few Super NES ones?


As of April 2017, the latest solution summary is on page 6.


Top
 Profile  
 
PostPosted: Wed Dec 02, 2015 10:33 am 
Offline
User avatar

Joined: Fri May 08, 2015 7:17 pm
Posts: 1787
Location: DIGDUG
Re: samples

Bregalad made a Wav to Brr conversion tool. You can make your own samples by recording live instruments or virtual instruments.
http://www.romhacking.net/utilities/681/

_________________
nesdoug.com -- blog/tutorial on programming for the NES


Top
 Profile  
 
PostPosted: Wed Dec 02, 2015 10:39 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19122
Location: NE Indiana, USA (NTSC)
I'm aware of tools like that. I was more concerned about the source of WAV files to put into that tool. Or rephrasing, where do ModPlug users get their samples?


Top
 Profile  
 
PostPosted: Wed Dec 02, 2015 11:26 am 
Offline

Joined: Wed Jul 09, 2008 8:46 pm
Posts: 236
Here's my two cents (I'm not a Modplug user, though):

I take samples from soundfonts, but I resample them and manually assign loop points to them utilizing Schism Tracker.


Top
 Profile  
 
PostPosted: Wed Dec 02, 2015 8:43 pm 
Offline
User avatar

Joined: Mon Sep 15, 2014 4:35 pm
Posts: 3075
Location: Nacogdoches, Texas
tepples wrote:
Are there any other excuses for plenty of NES homebrew releases and so few Super NES ones?

I always thought one thing that could be potentially holding it back is the somewhat unjustified reputation of the SNES's CPU, and how it's SLOOOOOOOOOOW. What doesn't make sense though is as to why they'd go to the NES instead though. Most people (if any even do) would probably go to the Genesis, and there is plenty of Genesis homebrew. I guess it's like this: there are people who want to make something fairly small, so they go to the NES, and if people are then trying to make something with greater production value, they go to the SNES or the Genesis and choose the Genesis because they believe it is a better platform to work with (possibly because of the above reason) or they are just nostalgic for it or whatever.

The reasons I wanted to work on the SNES over other systems is because:
1. It's my favorite system and I wanted to contribute to it in some way
2. I'm "nostalgic" for it (which contributes to reason #1) in that although I'm not 25 years old or whatever, I got it as a hand-me-down when I was about 4, and it was the first video game I ever played and owned as I first played it when I was 3, almost 4 (It's on an old vhs tape that has the date in the corner).
3. I liked the technical specs video hardware, as I thought they would be capable of nice looking games while being somewhat conveniently made for 2D graphics (although I was kind of wrong about that...)
4. I feel like many developers could have done better, and I want to "prove" that the SNES is capable of more than has been done on it. (Kind of ties in to #1)

Now, as I've worked on the SNES, I can say I'm not nearly as enthusiastic as when I started because of frustration with things that I would have thought would be obvious mistakes when designing a video game console. Easily the main problem are the sprites, as there is almost nothing intuitive about them on the SNES, most notably the vram situation. I just personally found the easily accessible technical specs for the SNES (Wikipedia basically) to be somewhat misleading, and I know many people like random limitations to work on stuff like this, but I don't want to feel like I'm being crushed by it. The NES is (obviously) worse in this regard, but everything is at least straightforward. If I had known about the Irem M92 when deciding to work on the SNES, I probably wouldn't have even started on the SNES, although I probably wouldn't have gone far with that because I never would have had the technical knowledge on how to program for old systems, so I owe the SNES that. I still plan to work on the SNES, but it's killing me. I write bunches and bunches of crap, but I don't see any improvement because in me trying to "show off" old video game developers and program something amazing, I've gotten myself stuck, with it being hard to go back and start over, and equally hard to push through, but I figure one side would be more productive. The problem is that if I start to write a giant, complex animation engine and vram finder and tile uploader that all work in harmony, I need all of them done at once to even test anything, so it almost feels like I'm not even doing anything because I never see improvement, unlike when I first was working on the system and learned how to make characters change colors and stuff like that. Even then, I should have been done with this long ago, even with all my dumb school work, but I can't help myself from trying to improve things as I go along making it, almost causing me to restart the same thing multiple times over and still not seeing any result. What I really should do is I should stick to finishing something, see some sort of result onscreen, and then trying to improve it instead of trying to do it all in one shot. I'm sorry for my little "rant", but this has just gotten to me, and I'm kind of afraid I'll quit someday.


Top
 Profile  
 
PostPosted: Wed Dec 02, 2015 9:03 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19122
Location: NE Indiana, USA (NTSC)
Espozo wrote:
I just personally found the easily accessible technical specs for the SNES (Wikipedia basically) to be somewhat misleading

How is wiki.superfamicom.org not accessible?

Quote:
The problem is that if I start to write a giant, complex animation engine and vram finder and tile uploader that all work in harmony, I need all of them done at once to even test anything

First load all of one character's animations statically into the 16K of CHR RAM dedicated to sprites, build your "giant, complex animation engine" around those 128 16x16 tiles, and get it working. From there you can refactor it to load the tiles dynamically, and possibly load frames into statically allocated slots per character, DKC style. What I just described, doing the simplest thing and then refactoring it for generality, is how I made the CHR RAM update engine of Haunted: Halloween '85.

So anyway, I get the idea: the Genesis is drawing people away. Might it be wise for me to revise one of my older projects to build NES and Super NES versions from the same tree, with identical game logic and just different graphics and sound code, to show how easy it is to step up?


Top
 Profile  
 
PostPosted: Wed Dec 02, 2015 9:28 pm 
Offline
User avatar

Joined: Mon Sep 15, 2014 4:35 pm
Posts: 3075
Location: Nacogdoches, Texas
tepples wrote:
I just personally found the easily accessible technical specs for the SNES (Wikipedia basically) to be somewhat misleadingHow is wiki.superfamicom.org not accessible?

Just look up "snes technical specs" and tell me where wiki.superfamicom.org is, because I didn't find it till much latter. Look at it through the eyes of a beginner. I probably shouldn't have said "accessible" though...

tepples wrote:
First load all of one character's animations statically into the 16K of CHR RAM dedicated to sprites, build your "giant, complex animation engine" around those 128 16x16 tiles, and get it working. From there you can refactor it to load the tiles dynamically, and possibly load frames into statically allocated slots per character, DKC style. What I just described, doing the simplest thing and then refactoring it for generality, is how I made the CHR RAM update engine of Haunted: Halloween '85.So anyway, I get the idea: the Genesis is drawing people away. Might it be wise for me to revise one of my older projects to build NES and Super NES versions from the same tree, with identical game logic and just different graphics and sound code, to show how easy it is to step up?

I wasn't trying to attack you... But yeah, I guess you could do what you just described. I really don't think the SNES would give you a hard time if you just tried to do something simple for it, like Super Mario World simple vs. DKC.


Top
 Profile  
 
PostPosted: Wed Dec 02, 2015 11:47 pm 
Offline

Joined: Wed May 19, 2010 6:12 pm
Posts: 2295
Let's see if I can break this down into steps.

1) Create a basic animation engine.
2) Implement the ability to DMA to a fixed slot.
3) Use a frame number queue (a seperate register for previous and next frame number) to limit DMA usage.
4) Do all the fancy tile searching stuff.


Top
 Profile  
 
PostPosted: Sat Dec 05, 2015 12:12 pm 
Offline

Joined: Fri Jul 04, 2014 9:31 pm
Posts: 788
Espozo wrote:
choose the Genesis because they believe it is a better platform to work with

By all accounts it is easier to work with. But I've never been bothered much by whether or not what I'm trying to do is easy (which may be why I have trouble finishing projects)...

Quote:
I feel like many developers could have done better, and I want to "prove" that the SNES is capable of more than has been done on it.

Maybe that's part of the problem.

If you want to knock something out quickly, the Mega Drive is often a better choice. And the NES attracts most of the Nintendo fans who just want to do something simple or "retro". This leaves projects that either need to be on SNES (and there's a pretty narrow window between "just do it on NES/MD" and "just do it on PC") or are done by fanboys who want to prove something at least in part to explore untapped potential in the hardware.

You, me, psycopathicteen, and a number of other SNES developers on this board are all apparently trying to push the system past what the commercial-era games did with it. This isn't a guaranteed recipe for failure, as d4s has shown, and there are of course people who don't mind working on modest projects that don't push the envelope, but this 'drive to exceed' could be a contributing factor in the relative scarcity of finished games.

Quote:
I'm kind of afraid I'll quit someday.

I felt similarly for a while after I got the idea to do this port I'm working on (I had done zero game design or assembly programming before that; they were both voodoo as far as I was concerned). I felt like my enthusiasm would fade after a few months. It hasn't. This could be partly because I haven't had much time to work on the project, so instead of getting tired of it, I have to keep tearing myself away...

It could also be because I've seen tangible (if slow) progress. I'm learning the system, I'm pushing the limits of what can be done with the PPU, and it doesn't really feel like I'm just spinning my wheels. If I'd tried to start actual development on day 1, I'd likely have gotten lost and given up - but I've been doing system tests and functional mockups, trying one thing at a time, and so far it's working. I'll probably do a simple game or two as practice before starting development for real, so I don't get bogged down by my own incompetent code design...


Top
 Profile  
 
PostPosted: Sat Dec 19, 2015 12:46 pm 
Offline

Joined: Wed May 19, 2010 6:12 pm
Posts: 2295
Espozo wrote:
tepples wrote:
Are there any other excuses for plenty of NES homebrew releases and so few Super NES ones?

I always thought one thing that could be potentially holding it back is the somewhat unjustified reputation of the SNES's CPU, and how it's SLOOOOOOOOOOW. What doesn't make sense though is as to why they'd go to the NES instead though. Most people (if any even do) would probably go to the Genesis, and there is plenty of Genesis homebrew. I guess it's like this: there are people who want to make something fairly small, so they go to the NES, and if people are then trying to make something with greater production value, they go to the SNES or the Genesis and choose the Genesis because they believe it is a better platform to work with (possibly because of the above reason) or they are just nostalgic for it or whatever.


It seems like if it weren't for its reputation of being slow, it wouldn't have ever been slow in the first place.


Top
 Profile  
 
PostPosted: Sat Dec 19, 2015 1:24 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19122
Location: NE Indiana, USA (NTSC)
On this weekend of the release of Lucasfilm's The Force Awakens, remember that Nintendo's attempt to reverse this perception of slowness was thwarted by Pixar, which now shares a corporate parent with Lucasfilm.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 291 posts ]  Go to page Previous  1 ... 3, 4, 5, 6, 7, 8, 9 ... 20  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 5 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group