It is currently Tue Nov 21, 2017 7:05 pm

All times are UTC - 7 hours



Forum rules


Related:



Post new topic Reply to topic  [ 292 posts ]  Go to page Previous  1 ... 12, 13, 14, 15, 16, 17, 18 ... 20  Next
Author Message
PostPosted: Tue Aug 01, 2017 2:33 pm 
Offline
User avatar

Joined: Tue Apr 05, 2016 5:25 pm
Posts: 146
tepples wrote:
Sumez wrote:
are you sure the major blocker in "stepping up" from NES to SNES isn't simply a lack of thorough and properly organized documentation (such as the Nesdev Wiki)

I mostly rely on Fullsnes nowadays. There's also SNES Development Wiki.

The former is thorough but not properly organized. The latter is properly organized but not thorough.

Quote:
FrankenGraphics wrote:
There are many who are interested in doing pixel art, that's true. But there seems to be relatively few who are interested in making assets that would actually work without conditioning for a target platform.

Would it be hard for artists to understand a description of mode 1 limits?

I think this is really a tool problem. My understanding is that pixel artists enjoy working with limitations. The problem is that existing tools like Aseprite don't really enforce palette-per-tile and maximum tile limitations. In essence, there's the act of making art, and then there's getting that art into the engine, but nothing to really connect those two together.

The Sega Digitizer System comes to mind. I wonder if it handled this sort of stuff transparently?

_________________
SNES NTSC 2/1/3 1CHIP | serial number UN318588627


Top
 Profile  
 
PostPosted: Tue Aug 01, 2017 7:33 pm 
Offline

Joined: Wed May 19, 2010 6:12 pm
Posts: 2361
Just take some generic pixel art, reduce the image to 121 colors in GIMP, posterize to 32 shades of RGB, then manually arrange the colors as 8 palettes of 15 colors, and modify the graphics if they don't fit.


Top
 Profile  
 
PostPosted: Tue Aug 01, 2017 7:45 pm 
Offline
User avatar

Joined: Tue Apr 05, 2016 5:25 pm
Posts: 146
Hand-optimizing pixel art that was designed without tile limitations in mind is probably easier said than done, especially if you're trying to squeeze as much as possible out of available VRAM.

_________________
SNES NTSC 2/1/3 1CHIP | serial number UN318588627


Top
 Profile  
 
PostPosted: Wed Aug 02, 2017 1:38 am 
Offline
User avatar

Joined: Thu Sep 15, 2016 6:29 am
Posts: 382
Location: Denmark (PAL)
tepples wrote:
Sumez wrote:
and good beginner tutorials?

How much of a job would it be to rewrite Nerdy Nights for Super NES?


Quite a demanding job, for sure. No one is denying that. But I'm sure you'd agree that the lack of such is a big barrier of entry to SNES development for most people, correct? I would love for one to exist, but wouldn't dare asking anyone to make it.

That said, personally I am more into "segmented" tutorials, describing examples of various individual things to do on the system. Ie. one tutorial to learn the CPU/assembly language, another one for best vblank practice, one for controller reading, etc. Makes it easier for me to focus at the task at hand. If I follow a "make a full game" tutorial, I usually end up just skipping through most of the text, copy/pasting the code that I need, and then immediately alter it to experiment or better suit my own future needs. I'm super impatient like that.

In fact, what I need, personally, might be more of a "template project" than a tutorial. I always found those immensely helpful.

HihiDanni wrote:
tepples wrote:
I mostly rely on Fullsnes nowadays. There's also SNES Development Wiki.

The former is thorough but not properly organized. The latter is properly organized but not thorough.

This echoes my own impressions from digging into those.


Top
 Profile  
 
PostPosted: Wed Aug 02, 2017 2:29 am 
Offline

Joined: Tue Oct 06, 2015 10:16 am
Posts: 582
FWIW, I find fullsnes is just fine. After all I managed with the same author's similar style GBA document without any issues.

So from my POV, the docs are adequate. If there was an acceptable C compiler, I could be doing SNES games right now.

edit: I know I'm probably in the minority with this opinion, but nerdy nights was useless to me. I had a decent compiler, and that tutorial wanted to teach 6502 asm in tiny steps, when all I needed was the system-specifc specs, which I found on the nesdev wiki.


Top
 Profile  
 
PostPosted: Wed Aug 02, 2017 6:30 am 
Offline
User avatar

Joined: Thu Sep 15, 2016 6:29 am
Posts: 382
Location: Denmark (PAL)
I agree that a tutorial definitely shouldn't try to teach you 6502 (or 65C02) along with the system in question, those should be kept separate. Sure, it's good practice to explain what each asm instruction does, but no need to start talking about what registers are, etc.
I have to admit I've never even looked at Nerdy Nights. Count me in with the "nesdev wiki" route.

fullsnes is neat, but it's definitely not "newbie" friendly. I look at it now and my immediate reaction is "but where do I start".


Top
 Profile  
 
PostPosted: Wed Aug 02, 2017 7:38 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19238
Location: NE Indiana, USA (NTSC)
Sumez wrote:
In fact, what I need, personally, might be more of a "template project" than a tutorial. I always found those immensely helpful.

I'm not sure what you what in a template, but I made lorom-template.

The answer to the wiki not being thorough is for those who already have Super NES programming experience to sign up and edit it.

As for narrowing a tutorial's scope, I guess one approach is to teach the Super NES hardware assuming knowledge of 65816 assembly. But then which are the two best 65816 tutorials?


Top
 Profile  
 
PostPosted: Wed Aug 02, 2017 7:50 am 
Offline

Joined: Wed May 19, 2010 6:12 pm
Posts: 2361
These have good 65816 information, and I think they're easy enough to understand.

https://wiki.superfamicom.org/snes/show/65816+Reference

http://www.defence-force.org/computing/ ... /annexe_2/


Top
 Profile  
 
PostPosted: Wed Aug 02, 2017 2:08 pm 
Offline

Joined: Mon Apr 07, 2008 6:08 pm
Posts: 325
Location: Missouri
A few years back I made a SNES romhack (that wasn't released) using a mish-mash of sneswiki and a demo program for the hdma feature as guidance. The fact I had working knowledge of NES and GBA already made SNES only a slight learning curve. But I wouldn't recommend it to beginning programmers (probably not any console over a PC with a library like Pygame or Allegro).

While some of the best games we'll ever play are on the 16-bit consoles (including MD/Gen and PCE/TG-16), I think they're the worst targets for homebrew dev because for all the complexity they're quite middling in what can be accomplished. This SNES homebrew release with choppy animation only bears that out.
https://www.youtube.com/watch?v=DtHbnYCccyU (4:30 to watch gameplay)

Still, if anyone insists, I can't see a SNES tutorial being effective without demanding prior knowledge of NES (likewise 65816 from 6502).


Top
 Profile  
 
PostPosted: Wed Aug 02, 2017 3:31 pm 
Offline
User avatar

Joined: Tue Apr 05, 2016 5:25 pm
Posts: 146
strat wrote:
While some of the best games we'll ever play are on the 16-bit consoles (including MD/Gen and PCE/TG-16), I think they're the worst targets for homebrew dev because for all the complexity they're quite middling in what can be accomplished.

This sounds rather defeationist to me, and Unholy Night as an example is rather disingenuous. I don't think that game's issues are strictly tied to the SNES. The quality of the art and music pales in comparison to releases from the 16-bit era. And heck, pretty much every other piece of SNES homebrew I've played was better programmed than this. It's almost like you picked this game specifically to discourage people from making homebrew.

I guess I'm just getting increasingly tired of the endless pessimism I'm seeing out of a thing that I actually think is Pretty Freaking Cool and deserves more attention than it's got.

Quote:
Still, if anyone insists, I can't see a SNES tutorial being effective without demanding prior knowledge of NES (likewise 65816 from 6502).

I have basically zero working knowledge of the NES and I'm doing fine. I also don't understand why 6502 knowledge would be a prerequisite to learning the 65816. In fact, I'm having a hard time imagining even programming an 8-bit processor. It just seems like something that would constantly get in your way.

Out of curiosity I've been browsing the NES section of these forums as well as some other NES resources. I know this isn't first-hand experience with NES development but it's still to me an eye-opener. Here is what I discovered:

- No native 16-bit arithmetic (obviously). There's so much game-related infrastructure I can think of that's, say, just barely outside the 8-bit range but is easily represented via 16-bit values. Timers, score, object positions, pointers, etc. etc. Yes, you can use the carry flag for addition and subtraction, but for comparisons it becomes more complex.
- You can't just follow a function pointer on the 6502. You have to do a song and dance with the stack to get it to work, and this costs significant CPU time compared to the 65816 which can do this natively. And function pointers are (IMHO) rather important to making code that's flexible and reusable.
- No hardware multiply/divide.
- To initialize RAM you have to use a tight loop in software. You can't just tell DMA to fill a region with zeroes.
- You can't use DMA to do nametable transfers.
- You have to resort to positional interrupt tricks just to get two large objects moving independently, and even then you're severely limited.

I'm sure there's more that I've forgotten. I've had a NES programmer pop in once while I was streaming SNES homebrew programming. They were in awe that I had 8kB of readily accessible RAM to play with. We take a lot for granted in SNES land.

As for past experience and working knowledge, I remember when I was looking into C/C++ programming and came upon the following advice: Essentially, don't learn all of C if you intend to be working mainly in C++, because you're going to be spending a lot of time unlearning old C habits that are counter-productive in C++, because C++ does some things differently. I suspect the same applies here. Yes, there is some transferable knowledge, but it'd be advisable that folks only train themselves in what is transferable, as anything else may just be an unproductive use of time.

_________________
SNES NTSC 2/1/3 1CHIP | serial number UN318588627


Top
 Profile  
 
PostPosted: Wed Aug 02, 2017 3:58 pm 
Offline

Joined: Wed May 19, 2010 6:12 pm
Posts: 2361
You forgot that the 6502 can't use it's index registers as 16-bit pointers, AND there is no normal indirect mode, just indexed indirect and indirect indexed.


Top
 Profile  
 
PostPosted: Wed Aug 02, 2017 8:07 pm 
Offline

Joined: Mon Apr 07, 2008 6:08 pm
Posts: 325
Location: Missouri
I've been looking for some SNES homebrew. The most interesting thing I came across (and it's not out yet):
https://www.youtube.com/watch?v=8bgBxtN0AGU

There's also N-Warp Daisakusen (originally freeware but also published on cart) and Super Boss Gaiden (SNES CD, yeesh). Of course one of the posters here (Shiru) did Classic Kong.

There are lots of great looking newer SNES games that actually date back to the 90's but were unreleased and picked up all these years later. Like Nightmare Busters and what's been published by Piko Interactive. Not exactly homebrew but at least someone is releasing new SNES carts.

Quote:
This sounds rather defeationist to me

I'm not trying to discourage anyone from SNES homebrew, per se. Since I've only made a rom hack, this is an imperfect judgment: On NES, the limitations are very clear and strict, so you can design the game around what can't be done. It seems to me on SNES you could go to a lot of trouble with getting part of a game done, then find, "ah gee, that doesn't work after all." And that's really apparent with Unholy Night. Possibly it was ineptly programmed but it just looks like assets were cut out to make it run with the animators begging for a more powerful platform. It could be the implementation was poorly planned all around, but it comes off like biting more than the system could handle.

Another reason for my attitude is the proliferation of co-processor chips in the commercial era. The Super FX (GSU) chip is its own discussion (we know exactly why it was needed in those games), but I couldn't look at Kirby Superstar or Super Mario RPG and tell you why they needed the SA-1*, while DKC and Tales of Phantasia didn't. Almost as if the cpu speed introduces a hidden limitation that could become a minefield despite the system's sprite capability.

* Though without debugging I'd guess off-hand they use the co-processor to load animation frames on the fly, since enemies in KSS are very detailed.

That said, I basically decided any game of mine for an older system will be backported from PC.


Top
 Profile  
 
PostPosted: Wed Aug 02, 2017 8:51 pm 
Offline
User avatar

Joined: Tue Apr 05, 2016 5:25 pm
Posts: 146
strat wrote:
Possibly it was ineptly programmed but it just looks like assets were cut out to make it run with the animators begging for a more powerful platform. It could be the implementation was poorly planned all around, but it comes off like biting more than the system could handle.

I've just been staring at the game's intro wondering how on earth it can choke on displaying fixed width text. That just isn't something that happens. Only thing I can think of is that they were programming in a (very!) high-level language. Even the launch titles run (and look) better than this.

Quote:
Another reason for my attitude is the proliferation of co-processor chips in the commercial era. The Super FX (GSU) chip is its own discussion (we know exactly why it was needed in those games), but I couldn't look at Kirby Superstar or Super Mario RPG and tell you why they needed the SA-1*, while DKC and Tales of Phantasia didn't.

Probably a combination of developer convenience, hardware decompression, and anti-piracy features. The fact that DKC doesn't need an expansion chip is a testament to, rather than a strike against, the base SNES system.

I feel like I have a _pretty good_ idea of how powerful the base CPU is from doing homebrew programming in assembly. I am currently doing some refactoring to allow support for streaming metasprites in my engine but before that's finished I plan to cook up a simple demo called 128 Birds. As the name would suggest, the demo is meant to be a more accurate indicator of the CPU's ability to handle large object and sprite counts at 60 FPS. And since it will be within the context of a game framework instead of an isolated tight loop, it should also be fairly indicative of real-world performance. I think you may be pleasantly surprised at just how much the CPU can do.

_________________
SNES NTSC 2/1/3 1CHIP | serial number UN318588627


Top
 Profile  
 
PostPosted: Wed Aug 02, 2017 9:23 pm 
Offline

Joined: Wed May 19, 2010 6:12 pm
Posts: 2361
It looks like Unholy Night might use the "Let's update as little as possible during vblank, and just make the game wait for the next vblank when it exceeds the arbitrary limit we set for it" approach.


Top
 Profile  
 
PostPosted: Thu Aug 03, 2017 1:57 am 
Offline
User avatar

Joined: Thu Sep 15, 2016 6:29 am
Posts: 382
Location: Denmark (PAL)
tepples wrote:
Sumez wrote:
In fact, what I need, personally, might be more of a "template project" than a tutorial. I always found those immensely helpful.

I'm not sure what you what in a template, but I made lorom-template.

Thanks, that actually looks genuinely helpful! I'm not gonna move up to SNES development any time soon, but I might try playing around with it a bit.

HihiDanni wrote:
There's so much game-related infrastructure I can think of that's, say, just barely outside the 8-bit range but is easily represented via 16-bit values. (...), object positions, (...)

This... so much this :P
Quote:
- No hardware multiply/divide.

I didn't even realise the SNES CPU had that! Now I'm even more intrigued.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 292 posts ]  Go to page Previous  1 ... 12, 13, 14, 15, 16, 17, 18 ... 20  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 10 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