Language…
15 users online:  AmperSam, dotCoockie, Golden Yoshi, Guido_Keller, itsmefigs, JezJitzu, Maw, playagmes169, PMH, Serena, signature_steve, Sparkz314,  Telinc1, timothy726, toady - Guests: 260 - Bots: 319
Users: 64,795 (2,377 active)
Latest user: mathew

I feel like SMW hacking is bogging SNES homebrew down

Link Thread Closed
Are any of you guys into any type of homebrew for other systems?
Originally posted by ft029
the mode 7 example isn't past the line yet.

But this:


Why this isn't a homebrew is beyond me.


I got into hacking because I grew up playing these old snes games as a kid and when I found out that I could edit some of my favorite games I got really excited.

When I first got introduced into hacking I noticed some hacks were of poor quality and I felt that a hack could be of equal or higher quality than the original game if done right.

I saw hacking as a way to honor my favorite games.

I am also a big SNES fan as I've been playing my SNES my whole life. A big goal of mine would be to make my very own SNES games from scratch. This way I can legally own the game. However, I don't know enough to code my own games.

I am more of a video game designer than a coder. I can code a little bit, but I'm still working on it. I am not at the level that I can code new blocks and sprites of whatever I want.

But with all the resources here, I can make many many games without all that coding. If this were a homebrew community instead of a hacking community my interest would be exactly the same as it is now.

I just have this fascination with creating games for the SNES. I've literally stared and played this system for so many years and now I can say that I can make games for it. For me, its a big time nostalgia thing.

Also for my game that I can working on Plextona, I didn't code any of those special things into the game. The biob did these and he is an amazing person. So if it were a homebrew then I wouldn't even know how to code anything or get anything to work.

I do wish that there existed a SNES homebrew game engine and program similar to what Lunar Magic is. Then I would be making my own homebrew games for sure and you would probably see lots of homebrew in general.

For my game Plextona, doing a hack is the next best thing to making a homebrew. Since I don't really have the abilities and resources to make it a homebrew, its going to be a hack. Unless someone wants to code a level editor or me with tons of sprites and blocks for me.

But I will say, I really like the idea of taking one game and transforming it into another game. For example I am really looking forward to the challenge of taking a 2D platformer and turning it into an overhead action RPG game. It makes you think in creative and interesting ways and I see it as an artform.
Originally posted by Drex
Are any of you guys into any type of homebrew for other systems?

I'd like to check out SEGA console homebrew sometime tbahaicpeb

yes i am aware that the saturn is ass to program on

Originally posted by Final Theory
When I first got introduced into hacking I noticed some hacks were of poor quality and I felt that a hack could be of equal or higher quality than the original game if done right.

The reasoning behind my ASM boner tbh, Sonic 1's hacking scene helped with that viewpoint's development lol

good luck with plextona, 2d zelda (also neutopia lol) is good shit
HackPortsASM"Uploader"

I get inspiration from Sega Genesis homebrew, and Genesis games in general.

Originally posted by Teyla

Of course you're going to get that reaction because people are telling you to go to a console where that is easier.


Except that the base SNES has 128kB vs 64kB for the Genesis so you can "cache" more rotating sprites at once, so the Genesis would have to do more in real time to compensate for it, unless you're using cartridge SRAM.

Also, my rotation routine relies on overlapping 16-bit writes to form pixel addresses, which is hard to do on the 68000 because it uses word aligned memory, and shifting is also pretty slow on the 68000.

Originally posted by Final Theory

I do wish that there existed a SNES homebrew game engine and program similar to what Lunar Magic is. Then I would be making my own homebrew games for sure and you would probably see lots of homebrew in general.


I'm alternating between Alisha's Adventure, and making a new general SNES homebrew engine for others to use, although I have to make sure I don't make it too confusing for anybody. Any mistake I made with Alisha's Adventure, I will fix for the new general SNES homebrew engine.

I have a lot of ideas on how to make sprite rotation even faster for the generic engine so I would have room to start doing other tricks such as sprite scaling.
Originally posted by Drex
I get inspiration from Sega Genesis homebrew, and Genesis games in general.

HAL Laboratory, pre-merger Square, Sega's coin-ops, Sega's Saturn+Dreamcast 1st party titles, SNK and Treasure are my baes

Traveller's Tales also did some cool shit sonic 3d is still garbage
HackPortsASM"Uploader"

The ironic thing is some of Vitor's SA-1 levels do make better use of the SA-1 than both Super Mario RPG and Kirby's Super Star.
Quit blaming all of your problems on the SMW hacking community.

If the SNES homebrewing community is in fact bogging down, it's on their own accord; not because a completely different community with an entirely different discourse came along and ruined everything. The SMW hacking community is not your scapegoat.

Your propaganda is garbage and your facts have proven no detrimental or even harmful effects on either homebrewing or any other ROM hacking community.
My layout has removed you.
Originally posted by Drex
The ironic thing is some of Vitor's SA-1 levels do make better use of the SA-1 than both Super Mario RPG and Kirby's Super Star.

...your point? Super Mario RPG and KSS used SA-1 for slowdown reduced things, not a full mode 7 level made by sprites only.
Hi, I'm a signature!
Hack Thread
Hack Testing Status: Available.
Layout by Koopster.
Originally posted by Konata Izumi
Originally posted by Drex
The ironic thing is some of Vitor's SA-1 levels do make better use of the SA-1 than both Super Mario RPG and Kirby's Super Star.

...your point? Super Mario RPG and KSS used SA-1 for slowdown reduced things, not a full mode 7 level made by sprites only.


Slowdown still wouldn't happen, unless someone did a really inefficient programming job.

Originally posted by Face
Quit blaming all of your problems on the SMW hacking community.

If the SNES homebrewing community is in fact bogging down, it's on their own accord; not because a completely different community with an entirely different discourse came along and ruined everything. The SMW hacking community is not your scapegoat.

Your propaganda is garbage and your facts have proven no detrimental or even harmful effects on either homebrewing or any other ROM hacking community.


It's not JUST the SMW hacking community that is the cause of it. I'm just trying to fight the spread of misinformation that's been around since the SNES came out.

There are MUCH MUCH quicker ways of drawing sprites onscreen, and quicker ways to do physics and collision than the usual routines you can find on the internet. What would you rather have? Spend 10% of the CPU speed drawing 1 sprite, or take 10% of the CPU speed drawing 128 sprites? A lot of people think optimization is about nitpicking code, but it's really a different programming approach.

I'm not trying to tell people they suck at programming. I'm just saying people should take what they learn with a grain of salt. You shouldn't just copy and paste code from someone without considering the possibility of a faster routine.

If somebody shows you a collision routine that takes 200 lines of code, and you think that is way too much for a collision routine, it probably is.

I actually learn more programming techniques from Sega Genesis programmers than I do from SNES programmers believe it or not.
Originally posted by Drex
I actually learn more programming techniques from Sega Genesis programmers than I do from SNES programmers believe it or not.

Aren't there more Mega Drive software programmers with computer software backgrounds (Amiga, Spectrum, C64...) than there are SNES programmers with the same sort of background? I feel like being used to different architectures and their limitations could help.

Also do keep in mind that Nintendo's coding isn't exactly the greatest either, there is a reason Pokémon Gold & Silver had space for a second damn region right after Iwata stepped in to tidy up the code.

Originally posted by Drex
It's not JUST the SMW hacking community that is the cause of it. I'm just trying to fight the spread of misinformation that's been around since the SNES came out.

Honestly, instead of making huge complaint threads like this, why not use your efforts to help ASMers and homebrewers optimize their code and share efficient programming techniques? Sorry if I'm coming off as bitchy.
HackPortsASM"Uploader"

Originally posted by lion


Originally posted by Drex
It's not JUST the SMW hacking community that is the cause of it. I'm just trying to fight the spread of misinformation that's been around since the SNES came out.

Honestly, instead of making huge complaint threads like this, why not use your efforts to help ASMers and homebrewers optimize their code and share efficient programming techniques? Sorry if I'm coming off as bitchy.


I do, it's just that sometimes my advice sounds like I'm making up complete nonsense, because it goes against common knowledge.
I suppose I don't see much actually meaningful "bogging down." How exactly would usage of more efficient algorithms/etc actually help developers with the real bottlenecks that prevent them from producing meaningful content? People come into SNES hacking and homebrew expecting a slow CPU and limited overall capability. They're not held back by lack of efficient algorithms.

I'm pretty confident most are held back by lack of available libraries and lack of tools; someone who just wants to make a game won't want to reinvent the wheel yet again. For example, someone wanting to make music for a homebrew almost certainly wants to get straight to composing and not faff around for a month making a sound engine. What they need is a pre-made sound engine and tools to compose and/or insert songs.

This is ultimately why SMW hacking (and other game hacking instead of homebrew) is popular. People most often want to design games, not game engines. You want to improve the underlying engines people use? Go for it! But it's ultimately just under-the-hood stuff that no one really cares about except that it lets them have more sprites on screen or whatever, since that's the end result that actually matters. And even then it's not really a big deal, since if people didn't want limitations they wouldn't be working on the SNES; they'd be coding a Unity game or whatever.

The best way to go about revolutionizing SNES development is to fill the voids. Create general purpose level editors, sound engines, scripting engines, etc. As it stands the best options are ones ripped straight from existing games, so people use those.
Originally posted by Kaijyuu
People come into SNES hacking and homebrew expecting a slow CPU and limited overall capability. They're not held back by lack of efficient algorithms.


https://wiki.superfamicom.org/how-to-display-sprites

Here is a tutorial on wiki.superfamicom.org about drawing sprites onscreen, with an example of an efficient algorithm. If you count the cycles (I forgot the exact amount), you would see that even 128 sprites would not exceed a CPU frame, and so programmers have no reason to be afraid of drawing sprites onscreen.

I counted the number of cycles:

95 cycles * 128 sprites = 12160 cycles. SNES has 57814 cycles per frame so this whole thing only takes 21% of a frame. You still have 79% of a frame to do game logic! See the SNES isn't so bad!
Originally posted by Kaijyuu
People most often want to design games, not game engines.

For sure.

What bogs down SNES homebrew is what bogs down homebrew in general. There will never be mass appeal in creating entirely new games from scratch on archaic computing platforms. It's a novelty, and to create a complete, polished game on any platform more advanced than a third-generation console is extraordinarily ambitious... even when you don't do it from scratch!

Romhacking is like building a custom car. Homebrewing is like building a custom car by personally machining all the parts yourself.
GANYMEDE

Chapter Two: Land of No Shame
I'm not saying hacking is bad. I myself hate starting everything from scratch.

I'm just trying explain that people SHOULDN'T be afraid of using sprites when they need to, because doing the math proves that the CPU usage of using sprites is negligible. Most people here act like using sprites is some CPU clogging last resort.
I will note that "sprite" is colloquially used around here to refer to the actors in the game, not just the tile(s) drawn in the OAM. SMW's actor routines are hella slow and inefficient, mostly due to lots of unnecessary looping and state checking.
How long does it take SMW to do collision detection between objects? Collision detection is another thing that really shouldn't be an issue, but gets fussed about a lot.
... I actually find it amazing that all your complaints about sprites were just the product of you not understanding SMW hacking terminology.
When people here say "SMW can only have 8 sprites running before it lags", they don't mean 8 OAM objects. They mean 8 fully coded entities that act in the game world, each drawing multiple tiles to the screen, running collisions and interacting with each other and the player.
That obviously is still not ideal, but drawing sprite tiles to the screen is not and never has been a source of slowdown or complaints in SMW hacking.
Your layout has been removed.
If anything, only NMSTL (which checks through every sprite slot when activated) and SMW's finish OAM routine really eats CPU time regarding OAM tiles and even then, people try or tried to optimise these routines.

Now, we still can tell you about the object interaction but for now, we haven't got the. You can ask Thomas as he know the engine pretty well. Else, wait till someone has enough information for the hitbox routine's inefficiency.
Vitor said that he needs the SA-1 to draw the foreground out of OAM sprites in the Mode-7 level. It makes me wonder how much of the CPU time is spent drawing the foreground, and what is just SMW running.

Originally posted by MarioFanGamer

If anything, only NMSTL (which checks through every sprite slot when activated) and SMW's finish OAM routine really eats CPU time regarding OAM tiles and even then, people try or tried to optimise these routines.

Now, we still can tell you about the object interaction but for now, we haven't got the. You can ask Thomas as he know the engine pretty well. Else, wait till someone has enough information for the hitbox routine's inefficiency.


Do I have these facts correct from memory?
1) In the original game, there were hardcoded different sized slots in OAM, and game objects looked for an OAM slot that matched it's size.
2) NMSTL is similar, but OAM slots get moved around depending on objects activating and deactivating, and objects need to look through OAM by counting how many blank sprite tiles are there in a row.
3) The "finish OAM" routine is the routine that determines the 9th X bit of a sprite tile, based on the sprite tile's X coordinate and the main sprite's X coordinate.
Link Thread Closed