It is currently Mon Oct 23, 2017 3:07 am

All times are UTC - 7 hours



Forum rules


Related:



Post new topic Reply to topic  [ 291 posts ]  Go to page Previous  1 ... 13, 14, 15, 16, 17, 18, 19, 20  Next
Author Message
PostPosted: Thu Aug 03, 2017 3:11 am 
Offline

Joined: Tue Oct 06, 2015 10:16 am
Posts: 558
Hw multiply/divide isn't that useful. Genesis has that, and IIRC it's faster than SNES's. Yet it's only useful for things done rarely, like score updates once per frame; for anything done more often, you have to use a table, just like on NES. And even on NES you have enough time to multiply or divide for rarely done things, it takes just a few scanlines.


Top
 Profile  
 
PostPosted: Thu Aug 03, 2017 4:31 am 
Offline
User avatar

Joined: Thu Sep 15, 2016 6:29 am
Posts: 253
Location: Denmark (PAL)
So after perusing the entire thread, I thought I'd bring up one thing that is surprisingly not discussed a whole lot, depite being pretty much the basis for the entire thread. Most of the talk has been quite technical (and extremely interesting, too!) in regards to the SNES hardware, and of course the bullet points tepples brought up, but I don't believe that is really the cause of the "lack of" a SNES homebrew scene.

HihiDanni wrote:
This sounds rather defeationist to me


This! This might be more obvious for me, having only picked up NES development last year, and thus seeing most of this from an outside perspective, but there's a very general pessimism surrounding potential SNES development, to the point where getting anything done is perceived to be near-impossible.

Throughout the years, whenever I've pondered the possibility of creating games for older consoles, SNES would always have been my first thought (after all, it's pretty much the most popular classic console to ever exist), but the ideas have always been shot down by people that I talked to about it. Usually it goes something like "SNES is way too difficult to develop for, that's why no one is doing it". Or "There's a C compiler for the MegaDrive, so I would recommend going with that". Hell, I know it makes no sense to point out in an NES development community, but I'll admit that even the prospect of having to code something in assembly was pretty daunting, especially when there's another, supposedly much more approachable, 16-bit alternative. And even now, looking at just the assembly code, 68K ASM just looks so much more simple and beautiful than 65816 or 6502. And let's not forget those myths still going around that the SNES CPU is "too slow", or supposedly the cause of slowdown in many SNES titles (lol, I know).

However, the reasons for this general attitude towards how "difficult" SNES development is, don't *really* matter. What matters is that it exists. There's a lot of prejudice going around, and the aforementioned "defeatist" stance is a pretty good example of what you see everywhere. If a bigger SNES development community needs to happen, that's the first obstacle that needs to be torn down and obliterated.
I guess actually just seeing some more finished homebrew projects would probably help it a lot. As to say "hey, a scene does exist!".


Top
 Profile  
 
PostPosted: Thu Aug 03, 2017 5:07 am 
Offline
User avatar

Joined: Mon Jan 23, 2006 7:47 am
Posts: 70
HihiDanni wrote:
[...] 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.

Indeed.


Top
 Profile  
 
PostPosted: Thu Aug 03, 2017 5:14 am 
Offline

Joined: Sun Mar 27, 2016 7:56 pm
Posts: 137
calima wrote:
Hw multiply/divide isn't that useful. Genesis has that, and IIRC it's faster than SNES's. Yet it's only useful for things done rarely, like score updates once per frame; for anything done more often, you have to use a table, just like on NES. And even on NES you have enough time to multiply or divide for rarely done things, it takes just a few scanlines.

Huh? I wouldn't say it's as slow as you're making it out to be.

In particular, the mode 7 multiplier (s16 * s8 = s24) is as fast as it possibly could be for an MMIO multiplier; the result can be read immediately as soon as you write the operands. The downside is that it can only be used freely in mode 0-6; in mode 7 it can only be used during vblank and forced blank.

There's also the unsigned multiplier (u8 * u8 = u16) which takes 8 CPU cycles before the result is ready, and the unsigned divider (u16 / u8 = u16 R u16) which takes 16 CPU cycles. Note, however, that even this isn't as bad as it seems, because other stuff can be done while waiting for the result. In addition, something like lda $4216 takes three cycles to read the instruction before it actually reads from $4216, so in practice you only have to wait 5 CPU cycles for the unsigned multiplier, for instance.


Top
 Profile  
 
PostPosted: Thu Aug 03, 2017 11:47 am 
Offline
User avatar

Joined: Mon Sep 15, 2014 4:35 pm
Posts: 3074
Location: Nacogdoches, Texas
strat wrote:
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.

Imperfect judgement for me too, but I think the difference between the NES and the SNES is that with the SNES, there's what can be done, and there's what can reasonably be done (what was done during the commercial era). Unholy Night definitely falls under the later, but as some have said, on the lower end of the spectrum, like Street Combat versus SNES Killer Instinct. I could think of many ways to improve Unholy Night; use HDMA to change BG3 colors (like my Metal Slug status bar mockup) and possibly move color windows (F-Zero health bar) to make the status bar more colorful, use BG3 as part of the background past the status bar, (possibly still using HDMA to change color) upload different background tiles depending on where the camera is, make characters larger and have more animation frames, and shrink the dumbass giant black bars. The last 3 would require a better vram engine, but it would definitely be possible with the perfect vram engine I've been trying to make forever. Going from the Neo Geo to the SNES just is not a good idea; it takes much more work and a lot of trickery to get near equivalent graphics on the SNES.


Top
 Profile  
 
PostPosted: Thu Aug 03, 2017 3:11 pm 
Offline
User avatar

Joined: Tue Apr 05, 2016 5:25 pm
Posts: 124
Espozo wrote:
upload different background tiles depending on where the camera is, make characters larger and have more animation frames, and shrink the dumbass giant black bars.

If you ask me, the elephant in the room is the game's framerate. This is precisely the sort of thing I mean when I say that even the launch titles were better than this.

Espozo wrote:
Going from the Neo Geo to the SNES just is not a good idea; it takes much more work and a lot of trickery to get near equivalent graphics on the SNES.

I think you are giving too much credit to "ex-SNK devs". The Neo-Geo era ended over a decade ago. People change, teams come and go. Rust builds. Projects can be mismanaged. By that same logic, Mighty No. 9 would have been a masterpiece.

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


Top
 Profile  
 
PostPosted: Thu Aug 03, 2017 3:13 pm 
Offline

Joined: Wed May 19, 2010 6:12 pm
Posts: 2295
@Espozo. When you program, do you start from scratch each time, or do you continue where you left off?


Top
 Profile  
 
PostPosted: Thu Aug 03, 2017 3:52 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19116
Location: NE Indiana, USA (NTSC)
I start from my accumulated libraries. But I often have to start from near scratch if there's a change in platform, a change in employer, or a change in genre. And libraries are one thing we need.


Top
 Profile  
 
PostPosted: Thu Aug 03, 2017 11:47 pm 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7235
Location: Chexbres, VD, Switzerland
HihiDanni wrote:
This seems largely nonsensical to me - the world certainly has no shortage of pixel artists.

This completely miss the goal/purpose of making your game in solo, through. On the NES it's easier to make your game in solo, because the level of skill required to compose music for only 4 channels and do graphics for only 3 colours per tile is accessible to an all-round talented programmer. Sure, we might not put the system to its limit but still get a level of detail comparable to commercial games of that era. On the SNES you'd either use a fraction of the system's possibilities, or mount a team with people dedicated for specific art. This is not specific to SNES, though. Any more advanced platform has the same issue.

Also the lack of C is a pretty bad excuse, considering how controvertial it is how good this language is in the first place.


Last edited by Bregalad on Fri Aug 04, 2017 2:07 am, edited 3 times in total.

Top
 Profile  
 
PostPosted: Fri Aug 04, 2017 12:13 am 
Offline
User avatar

Joined: Thu Sep 15, 2016 6:29 am
Posts: 253
Location: Denmark (PAL)
It's a really bad excuse, but it definitely does have some effect on the general prejudice around development for the two major 16-bit consoles.


Top
 Profile  
 
PostPosted: Fri Aug 04, 2017 1:13 am 
Offline

Joined: Tue Oct 06, 2015 10:16 am
Posts: 558
Quote:
considering this language is a rather bad language in the first place.

*avoids flame*

@Sumez
How so? I am not exaggarating when I say asm is in general over 10 times slower to write. It is simply not worth my time to write an entire game in asm, nor worth anyone's money to pay somebody to do so. That alone is the reason some recent Kickstarters were quoted above 10k for a SNES port, it's that laborious.

Having a game cost 10 times more, without being 10 times more fun, is simply a non-starter.


Top
 Profile  
 
PostPosted: Fri Aug 04, 2017 1:37 am 
Offline
User avatar

Joined: Thu Sep 15, 2016 6:29 am
Posts: 253
Location: Denmark (PAL)
I get what you're saying, but assembly also has a way worse reputation that it deserves, and I definitely don't see why it should keep people away from creating SNES games.

You need to write assembly to make games for the NES, and that doesn't keep people away. (sure there are some nice examples of NES games created in C, but I'm sure we can all agree on the massive overhead it creates - there's a reason this entire forum is extremely focused on the 6502)


Top
 Profile  
 
PostPosted: Fri Aug 04, 2017 2:46 am 
Offline
User avatar

Joined: Mon Jan 23, 2006 7:47 am
Posts: 70
calima wrote:
Having a game cost 10 times more, without being 10 times more fun, is simply a non-starter.

But the game might be 10 times faster.


Top
 Profile  
 
PostPosted: Fri Aug 04, 2017 5:05 am 
Offline
User avatar

Joined: Tue Apr 05, 2016 5:25 pm
Posts: 124
I'm pretty sure both Classic Kong and Christmas Craze were written in C and they seem to run fine. I wouldn't use C for stuff with large object counts but I think the option is there for quite a few different kinds of games.

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


Top
 Profile  
 
PostPosted: Fri Aug 04, 2017 5:22 am 
Offline
User avatar

Joined: Thu Sep 15, 2016 6:29 am
Posts: 253
Location: Denmark (PAL)
Whether the existance of a usable C library is a valid argument or not is a moot point anyway. I mean, if someone were to build an actually useful library for the SNES, it would obviously help push a lot more people into SNES development, but even when it doesn't, my original point was that that really shouldn't keep people away from it. Or at least not to the point where a homebrew scene for the platform is almost non existant.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 291 posts ]  Go to page Previous  1 ... 13, 14, 15, 16, 17, 18, 19, 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