[ 3 / biz / cgl / ck / diy / fa / g / ic / jp / lit / sci / tg / vr ] [ index / top / reports / report a bug ] [ 4plebs / archived.moe / rbt ]

2017/01/28: An issue regarding the front page of /jp/ has been fixed. Also, thanks to all who contacted us about sponsorship.

/vr/ - Retro Games

View post   

[ Toggle deleted replies ]
File: 6 KB, 737x120, 7cc8.png [View same] [iqdb] [saucenao] [google] [report]
2447092 No.2447092 [Reply] [Original] [archived.moe]

In this thread we come together to build a small SNES game from the bottom up. Feel free to provide ideas, artwork, or programming.

I will lead the thread and provide technical explanations and programming, so don't worry if you know nothing about coding, computers, or SNES hardware because this thread is for exploring what makes games run. Everyone can contribute something.

To keep things simple and accessible to everyone, there will likely be no sound, but this isn't an absolute. Also we should consider a non-scrolling type game (think Asteroids, Frogger, Pac-man etc, as opposed to Super Mario Bros. et al).

To start things rolling, suggest some game ideas. Be creative and have fun!

>> No.2447097

How about a old school brawler where you play a bear that rapes children?

>> No.2447124

I loved the section in Illusion of Gaia, after Will survives his raft getting wrecked. He's saved by a dog named turbo and a fisherman brings him in.

How about a game about an old dude and his dog living near a remote beach. Occasionally shit will wash up on the beach. Maybe the story is told through bottle messages. Perhaps a mystery brews through the information he gathers on the beach? It could be a heartwarming / comfy game or a thrilling mystery.

Real time clock determining what washes up or fish in the water.

Game takes place over a few months.

Relaxing music.

Every day something unique is found - maybe it gets added to a shelf in his home? Randomly generated objects so no two experiences are the same?

>> No.2447127

Let's port Draw a Dinosaur

>> No.2447136

You don't even need the relaxing music. Just program the waves hitting the beach and maybe some seagulls?

>> No.2447154

This project won't go further than ideas.

>> No.2447172



Who knows how to program in 65C816 ASM?

>> No.2447180

... I do, but I'm lazy so yeah.

>> No.2447283

How about pong but with instead of linear bounces, the trajectory would be a random trigonometric function relative to the speed you're moving vertically?

>> No.2447296

a gameboy style single screen puzzler like boxxle, cyraid, kwirk, cat trap should be relatively easy to program.
If you want to be fancy about it make every screen be part of a larger map like battle kid, jet set willy, ufouria and add in some metroid/igavania elements

>> No.2447317
File: 42 KB, 960x886, 1428844144479.png [View same] [iqdb] [saucenao] [google] [report]

OP here. I know the 65816 like the back of my hand.

I really like this idea, but I think
is thinking in the right direction. Let's throw around some puzzle or 1 screen platformer ideas and mechanics.

Otherwise this faggot has a chance of being right.

>> No.2447321

>Otherwise this faggot has a chance of being right
>this faggot
Professional studio artist here. If anything gets made I give my word I will do concept design and illustrations for absolute free.

>> No.2447326


>make a game

VERY hard. It's actually way easier to create a PC game that has an engine that mimics 16 bit consoles. You need to know how to write an engine geared specifically for the sorta complex and archaic Super Nintendo.

It might be easier to use Super Mario World as a basis and romhack that since it's such a well understood game. No clue what the limits for that game engine are.

So the first question would be:

>What do you want from the game, in terms of action and then build an engine for that. Is it gonna be fast scrolling, slow scrolling, mode 7, etc.

Reminder that snes games had budgets in the hundreds of thousands. Do you think a bunch of nerds on a forum can do better?

>> No.2447328


Didn't the SNES use proper coding languages for games, which were then turned into ASM? I believe the 16 bit consoles were the first where you didn't have to write directly to ASM.

>> No.2447334

>Reminder that snes games had budgets in the hundreds of thousands
That budget was used mostly for marketing. Also no one things about making a fully featured game. It's more a minigame project than anything else.

>> No.2447338

I would play this.

>> No.2447339


I wasn't including marketing.

I actually don't know the budget for any SNES game, so I was just guessing. I heard that Symphony of the Night's budget was 1.5 million. That's a bit more detailed and bigger than a SNES game, but SNES games are probably in that ballpark. FFVI I can see costing a solid 1 million.

>> No.2447340

This. I started this thread so people can see how things work, not to make a full fledged commercial AAA game. Even so we can make something fun. I'll post some examples of my previous games to show this is totally doable.

>> No.2447352

Find the loli and escape the Hansen?

>> No.2447365

I think it's important to tell us stuff about the way things are programmed.

Sgea Genesis has a devkit made by fans but what about the SNES?

>> No.2447370

I'll do that after work when I have time to expouse. Ideas come first; no technical knowledge required.

>> No.2447378

Will it have mode 7? (Sorry for my bad english.)

>> No.2447402
File: 655 KB, 1195x652, piersolar01.jpg [View same] [iqdb] [saucenao] [google] [report]

Have there actually been any SNES homebrews?

Because Genesis had a bunch. pic related

>> No.2447428

Yes, more than genesis.

>> No.2447441
File: 45 KB, 314x239, 129045821628.jpg [View same] [iqdb] [saucenao] [google] [report]

I envy you OP. I tried to learn a bit of assembly back in the day to make simple NES/SNES homebrews, but that shit's like hieroglyphs to me.

But I'd be glad to contribute graphics or music, if it ever comes to that.

As for the gameplay, how about a top down shooter? It could take place within a single screen, where waves of enemies are coming after you, every so often a boss appears, and you have to survive for as long as possible.

>> No.2447454

Like what?

>> No.2447473

>It might be easier to use Super Mario World as a basis and romhack that since it's such a well understood game. No clue what the limits for that game engine are.
>Reminder that snes games had budgets in the hundreds of thousands. Do you think a bunch of nerds on a forum can do better?

You shouldn't use yourself as a benchmark to judge other people. You even admit you have no clue. Why even bother commenting if you don't know what you're talking about?

>> No.2447476

This sounds about right.
I know the SNES VRAM/OAM limitations so if it's alright I could post a bunch of graphics later this week.

>> No.2447495

8 bit architecture is so much more pleasurable though

>> No.2447497

Make a gane like tower of heaven but focused on a snes style rather than the gameboy aesthetic the original uses

>> No.2447502


>> No.2447504

I myself am more aware of the NES' graphical capabilities. What are the limitations of SNES graphics, sprites and background, except for the palette?

>> No.2447510


>> No.2447521
File: 198 KB, 400x284, 1430039301036.png [View same] [iqdb] [saucenao] [google] [report]

Thanks mate. I don't understand much of this stuff yet, but I'll try to wrap my head around it

>> No.2447524

SEP #$30

>> No.2447528

lda #$FF

>> No.2447570

A puzzle game where you have to escape from a bathhouse.

The puzzle aspect could be diverting the water flow.

>> No.2447574

Fuck stupid ass puzzle games we need a fucking rpg

>> No.2447590

Yes, this would definitely be the easiest and most simple project to manage on an anonymous imageboard. 👨🔫

>> No.2447592

>underage b&

>> No.2447638

and it's dead already

>> No.2447650

Some peeps got to work faggot. This thread better stay alive for two weeks. That's all the time it needs.

>> No.2447660

Who works in an environment where you can't access 4chan all day? I've been basically getting paid to monitor /vr/

>> No.2448057

dead as fuck

>> No.2448071

I'd be down for programming

>> No.2448134


Down for deez nuts?

>> No.2448151

got eeem

>> No.2448350
File: 119 KB, 500x603, 1370278771834.jpg [View same] [iqdb] [saucenao] [google] [report]

OP here back from work.

For an idea of the scale of game that we should try to make, here are a few I've put together in the past:

filedropper.???/phoenix_1 replace ??? with com. stupid filter

Let's review the ideas of the day:
>>2447097 Brawler
>>2447124 Sea shore sim
>>2447283 Already made pong (added spike mechanic)
>>2447378 Something with mode 7
>>2447441 Shmup
>>2447497 Tower of Heaven
>>2447570 Water flow game
>>2447574 Fucking RPG

I like the brawler idea, but AIs complicated, and 2p is easy. Sea shore sounds cool, but too involved for this project. Try my pong if you want. Good mode 7 would need HDMA, which I also think is too involved. I really want to make a shmup, but once again AI. Tower of heaven is a scroller, so to simplify things, no. I have a water flow game in the back of my mind, and even though I think this is a great idea, I think a fast game will be more engaging for this thread. RPG would be relatively easy, but I want to keep the 'game modes' to a minimum (ie world map, battle screen, map transitions, etc.).

So this is what I propose: a very simple 1 screen 2d platformer/fighter with a gravity switch mechanic that's jointly controlled by the players. Players can attack like link in Zelda 2 (maybe no duck, but block). Gravity is controlled by a counter both players can increment/decrement at will.

Tight play control will be balanced by frantically trying to switch gravity at inopportune times.

I'll wait for some feed back, but then we'll start getting down to business.

>> No.2448681


>filedropper.???/phoenix_1 replace ??? with com. stupid filter

Ok , this shit is fucking impresive.
What assembler do you use? WLA , xkas?

>> No.2448834

A game like the regular (not SUPER) Mario bros would work.
Still, the sea shore game is the idea I like the most

>> No.2448876


first of all i'm all for new snes games, and if someone could make that a reality, that would be great.
The language sounds...hard, and i seriously envy OP for knowing it.
The beach game sounds great and i would gladly give it a try.
My two cents for a game? A fantasy/sci-fi game where a knight on a triceratops pulverizes hordes of enemies through a strange planet.

the best of luck on your endeavor guys!

>> No.2448915

wrote my own.

>> No.2448994

What if we make this a JRPG similar to Final Fantasy?

>> No.2449021

There just aren't enough of those, are there?

>> No.2449112


>> No.2449269
File: 60 KB, 1071x803, unnamed.jpg [View same] [iqdb] [saucenao] [google] [report]

DAY 1 =====================================
OP Here.
I've included a picture that fleshes out my game and mechanics.

Once again, for this project, SMB might be a tad ambitious. However if yo like the sea shore game, could you please outline exactly how it would be played? The initial post was good, but I'm talking about specifics now.

Once we get our ideas down, we can then start to work on art/programming.

>> No.2449279

Pretty neat concept, but
>Gravity is controlled by a counter both players can increment/decrement at will
Oh boy, I can't wait for >that guy who's gonna spend the whole match mashing the L/R buttons everytime you approach him
Maybe disable the ability for a few seconds after using it?

>> No.2449281

I was just thinking the same thing. Freeze for a couple of seconds after a switch. Also maybe 'votes' to change count x2, while votes to remain the same count one. That way no dead lock. I think it would be fun for a down stabbing opponent to have gravity switch on him and be on the receiving end of a up stab.

>> No.2449283

What do you mean by 'votes'? Like, a pre-match poll to decide how long the ability disable will last?

>> No.2449290

So I'm assuming there will be multi-tap support, otherwise voting would be pointless.

>> No.2449301

By 'votes' i mean that both players have a dedicated gravity/anti gravity button that increments or decrement a gravity meter. At anytime when a player pushe a button during gameplay, they 'vote' on what the gravity should be. Gravity will be a binary thing; one way or the other. Also I think when a switch occurs, it should max out the meter in one direction such that gravity can't switch rapidly (unless maybe if there is a power up that changes this temporarily).

>> No.2449323

so fucking cliche

>> No.2449325


>> No.2449339

I meant Mario Bros (explicitly NOT SUPER mario bros)


The stages of which ironically resemble the ones in your concept.

>> No.2449372
File: 44 KB, 500x772, 500px-A_yogi_seated_in_a_garden.jpg [View same] [iqdb] [saucenao] [google] [report]

Oh, yeah. Never played it (outside of SMB3) but yeah, it bears some resemblance, but you could say it's a little Joust like too. Sorry, I read that as SMW.


Thanks for bumbing the thread.

>> No.2449518

Why not just have it be that any button press used for character control decrements the "presses until switch" counter? That way there's guaranteed to be a steady stream of flips, but if you want control over them you have to derp around.

>> No.2449645

Most devs used a devkit that used C, with certain things hand optimized in asm

>> No.2449775

You are just pulling that out of your ass.
A few games were wrote on C , IIRC some late RPG by squaresoft like Treasure G "maybe" were wrote in C
65xx processors and C didnt like each other ,
so anything that you wrote by yourself in ASM always gonna be better than what the compiler generates.
The 65816 is a simple CISC CPU and in the 90s almost everthing related with games was wrote in pure ASM.
Its totally posible to write games in C for SNES and you have an excelent library called pvsneslib , but dont expect a very good performance.

>> No.2449802

Hey look, we've got an ex Square dev from the 90s here.

You are correct, though. Most SNES games were written in assembly, with some things done in C.

>> No.2449813

>Hey look, we've got an ex Square dev from the 90s here.
Just ask on nesdev/romhacking/SMW or ask any scener and you will get the same response.
>Most SNES games were written in assembly, with some things done in C.
No , so don't misinform the people

>> No.2449871

Hello Espozo, still trying to make something out of your life? What a nice and original idea you got here, I'm sure this will lead to great things, knowing this awesome community of retrogaming experts.

>> No.2449883


>> No.2449884

Expozo like the old Totse member? Seems like most of us Totse OGs jumped ship to here.

>> No.2449930

This Expozo guy is spamming the fucking nesdev forum with stupid ass questions.

>> No.2449938

Hmm. Interesting. It sounds like his MO

>> No.2449946

Bumping for professional translations.
I can do italian, portuguese, french and spanish to IBM technical manual standard. (My job)

I can also seed the icelandic and german translations, but a native speaker would have to proof read for fluency.

Probably not much for this game, but thats what I can contribute with at my best capacity.

Also, new threads should be maintained using the game name as a title.

Lets get this going?

>> No.2449952


>> No.2449960

Metodo operandi.

Things he does as a routine.

>> No.2450136

I thought it was modus operandi, but yeah. Things he does as a routine.

>> No.2450223

COLOR a Dinosaur. Even more boring than drawing a dnosaur.

>> No.2450257
File: 62 KB, 793x600, american-flag-bald-eagle-45435.jpg [View same] [iqdb] [saucenao] [google] [report]

A classic jRPG where you play as classic AMERICAN stereotypes.

>so, Earthbound?
No, AMERICAN, ALL-AMERICAN, like soldiers, cowboys, bimbos, niggers, hamburgers, bald eagles and jews. Maybe a clash of generations, the current MURRIKA (FUCK YEAH!) vs the Norman Rockwell's America, with chiptune Frank Sinatra and all that jazz vs chiptune hip hop.

All in classic jRPG fashion, with turn-based battles and anime artwork.

I'm not a good artist, but I'm a good character design and I would love to design the characters.
Also, I'm not even murrikan. I'm BR.

>> No.2450340
File: 1000 KB, 1024x768, 456714-mwc_wp1_1024.jpg [View same] [iqdb] [saucenao] [google] [report]

>A classic jRPG where you play as classic AMERICAN stereotypes.

So Metal Wolf Chaos in RPG format? I'd be down for that.

>> No.2450360

Sorry, I'm an adult.

>> No.2450415
File: 18 KB, 200x236, 1374458209022.gif [View same] [iqdb] [saucenao] [google] [report]

OP here. So am I. I just busted ass for 12 hours and am briefing a government agency on Tuesday in DC. But I like my hobby and I need a release. Anyhoo, didn't have time to monitor the thread much today, but let's see what's up.

I think once the rest of the game is programmed, how exactly the gravity switch mechanic works can be easily experimented with to find something fun.

I read a while ago that NBA Jam was an unusual game because the programmers did it all in ASM, which leads me to believe official developers had access to C compilers furnished by the licensing company (Nintendo, Sega, etc). Anyway I decided to write my own because I couldn't find a decent one years ago.

Unfortunately I think an RPG is out of the scope of this thread at this time. I really want to do an RPG bad because I think it'd be relatively easy, but I need to put together a few more tools (like complete my SPC700 assembler) before I'm ready to tackle that.

I think I started this thread more to show people how game design is done, how to make a game, let people collaborate on things outside their expertise to build interest in hacking, and be a general "what's under the hood thread". The game needs to be simple in order to complete this project. If successful, I'd be delighted to make an RPG with you guys in the future.

>> No.2450420
File: 10 KB, 258x195, 125012896_Sonic_Derp.jpg [View same] [iqdb] [saucenao] [google] [report]


Since no one else has forwarded a more complete game design than the gravity fighting one, I'd suggest any one who wants to do character art or background design could start.

Here are the limitations I'll impose, and this applies to both backgrounds and objects (sprites): you get to define 8x8 pixel tiles which can select from 8 palettes composed of 16 colors each (including a transparent color). Additionally backgrounds are restricted to be on a grid 32x32 tiles large, and you get 2 layers of these grids (think foreground and background). Objects aren't required to be on a grid, so you can overlap tiles on top of each other (if for instance you wanted to draw body and arms separately).

Don't worry about the technical details yet. We'll map them to SNES graphics soon enough. I just want to see some ideas.

Since I can code, and am one of the few folks in this thread who can, I leave it in your hands /vr/.

Unfortunately I've got a shit ton of work due tomorrow morning, so I can't do much else tonight, but wait for the weekend.

>> No.2450425

Where you at in DC? Georgetown reporting in.

>> No.2450429

Not there yet, flying in.

>> No.2450448
File: 846 KB, 500x500, tumblr_nizzhwF1aM1qzbj7zo1_500.gif [View same] [iqdb] [saucenao] [google] [report]

One more thing: tiles and pallets can be swapped every frame for animated effects if you're feeling fancy.

>> No.2450457

something about this whole thread reeks of children...
nothing will ever get made.
I'm willing to bet money on it

In the extremely off chance it does, it'll be so autistic and horrible it'd be better off not made anyway

>> No.2450495

I sugested the RPG for fun. I knew it would be out of scope, but would be a fucking great game if done the right way.

For something simple maybe an arena fighting game, like Sonic Battle, Rakugaki Showtime and Power Stone.
Simplify it to the extreme. One screen, two characters.

>> No.2450498

Spoken like a true adult :^)

Hope? Enthusiasm? Fun?

Bah -- That's kids' stuff.

>> No.2450510

So this is all going to be coded in assembly, or what?

>> No.2450515

Has to be. I helped make a shit C compiler on top of my assembler, but it had no optimizations, so the output code was horrendously efficient (it worked though). I have previous code to pull from for a generic engine framework, NMI routine, and sprite drawing subroutines, but everything else will be from scratch.

>> No.2450523

I know it's not really /vr/ but if you have these skills, why not make a game for a modern platform?

>> No.2450551

it kind of is

>> No.2450576

Dang, I'd have liked to help with the coding but I'm not proficient with assembly. Oh well.

>> No.2450620

I hope this pans out. Would be really cool. Once all the ideas and logistics are flushed out how long do you think it will take to code? Guessing this will have to be continued on new a thread?

>> No.2450637
File: 1.04 MB, 1000x1347, NintendoPowerVolume62Page64.jpg [View same] [iqdb] [saucenao] [google] [report]

Frankly I don't want to suck the fun out of my hobby by making it my job. Also I love mathematics, physics, and engineering, and find them to be more worthy as lifelong pursuits. Nature hides great beauty.

That said, I have recently been looking into the Android API, I have implemented my own 3d graphics rendering pipeline, and love to see my programs brought to life (although coding can be a chore). I've thought about programming games for smart phones, or maybe doing visualizations for bands (think Big Gigantic, their light guy is essentially the 3rd member of the band) as a side job.

However I think I like programming old shit because it helps me recapture the little bit of how I felt towards vidya as a kid. Games were hard to come by and you used a lot more imagination to give them life. Also I like the challenge of balancing realism with limited resources and fun.

>> No.2450645

It's taken me less than 2 weeks in the past to program little games in my spare time. See >>2448681

I got a big boy job now with some deadlines breathing down my neck, but give it 2-3 weeks. I'll post all code and progress as it gets made.

Thinking of which, I really need to get off /vr/ for the night.

>> No.2450654

I'm a musician and have composed some stock music. I would love to make some 8-bit sounding stuff.

>> No.2450671

Final post for the night: I haven't written an SPC700 assembler completely yet, and that's what makes the beeps and boops on the SNES. However I have fully disassembled Super Metroid's sounds engine and sequencer, though I have severe reservations using copyrighted code in a game I may post on my website.

I have written a codec for the SNES, so it's not impossible, just out of reach for the moment. Maybe one day we can work something out. For the time being I give you my only audio gift: Super Fucktroid.

filedropper.???/superfucktroid ???=.com

>> No.2450742

Kinda like Nidhogg?

>> No.2451243

DAY 2 ==========================
We might have a few artists working on graphic concepts, which is nice, but not 100% sure. After work today I'll sit down and lay the foundations of the program and code the reset routine to wipe the system clean. I'll also explain a little about the structure of a game program.

>> No.2451250

No. Like this, but way more simple.

>> No.2451259

>After work today I'll sit down and lay the foundations of the program and code the reset routine to wipe the system clean.
or you can use the routine inside the file "InitSnes.asm"


>> No.2451271

I only have one request OP, share the source code, and make it GPL.

>> No.2451284

Don't worry, I'll share, and I don't need no stinking license. Just have it.

>> No.2451285

>a bear that rapes children
how about instead of a bear, a cheerleader

and instead of children, cheerleaders

>> No.2451489

Licenses are important because otherwise it still counts as copyrighted. At least use WTFPL

>> No.2451541

^what this anon says

>> No.2451557

OP, can you take a video of one of your games?

Also, does it have to be SNES homebrew? Why not just a SNES-style PC game? Would probably make programming it easier.

>> No.2451581

What the fuck is the point of making "SNES-style"? What the fuck does "SNES-style" even mean? That's not retro, anyways.

>> No.2452010

Oh My God Doom, my idea exists and its even for SNES.

>> No.2452060

that sounds fucking awesome, i'm so down for this you have no fucking idea.

>> No.2452064

I imagine someone flipping gravity, you almost hitting the spikes then flipping it again, and a downward stab.
It's like joust, link 2, and metal storm in a multiplayer format.

>> No.2452070

We should honestly just use stick figures like nidhogg, maybe even an attack system like nidhogg

>> No.2452080



Jesus, cut that fucking voice out, this isn't fucking Charlie Brown.

>> No.2452321
File: 156 KB, 480x640, IMG_2945.jpg [View same] [iqdb] [saucenao] [google] [report]

I already own a game like that, anon.

>> No.2452418 [DELETED] 

OP like usual, is a massive faggot

>> No.2452448 [DELETED] 
File: 428 KB, 706x477, Recoome_8.png [View same] [iqdb] [saucenao] [google] [report]

OP here. You might want to move out of your mom's basement and brush your teeth because you breath reeks of cum.

Day is done. Gone the sun. Time to hack. I'll be back.

>> No.2452449

There's this thing called public domain.

>> No.2452461

I don't believe in software copyright. I won't violate somebody else's copyright (actually I did for the first time ever in this thread, and probably never again because I could have uploaded a patch), but I also won't put some legal bullshit at the top of my code that's longer than the fucking file. If I don't pursue the copyright, it's like the copyright doesn't exist. I don't care what people do with it after it's published, even if they somehow can monetize it, because I'm not going that far with it. Call me dumb, but that's how I feel.

>> No.2452463
File: 4 KB, 243x185, title.gif [View same] [iqdb] [saucenao] [google] [report]

>Dat Nigger Jim
God bless those nips and their lack of racial sensitivity

>> No.2452505

It's a great JRPG, I know enough JP to get by playing it but I couldn't stand a chance properly translating it to English.

Maybe one day..,.,.,.

>> No.2452536

Holy shit you really are a fucking faggot

>> No.2452543

Sanic the Hedgehog.

>> No.2452551

Any other untranslated JRPG recommendation outside the usual suspects? I'm mostly familiar with the Hokuto no Ken RPG trilogy of 3-5.

>> No.2452589

Cool. It's been a while since I got my assembler working, but I can assemble my old games, so now time to gut them to get a fresh start on the code.

I'm going to track the project on github. I won't put my assembler up for grabs but the code will be there. My reasoning behind not putting the assembler up is because I wrote it when I was young, have learned a great deal about what a proper assembler should be, and have designed a much more powerful assembler that I still haven't written yet. Regardless the one I'll use is solid, but the syntax and directives are unique.


>> No.2452602
File: 12 KB, 513x451, palette_viewer.png [View same] [iqdb] [saucenao] [google] [report]


>> No.2452631
File: 16 KB, 416x400, Standard_Model.gif [View same] [iqdb] [saucenao] [google] [report]

One more thing guys. I'm going to need some basic graphics soon. If you leave it up to me this thread will be a spectator sport. If you want to throw down follow the restrictions here >>2450420 . Use YY-CHR to make graphics.

>> No.2452943

Oh shit. Like CT at the very beginning scene. Very ambient.

>> No.2453049

ITT OP comes up with a shitty game idea and tries to get other people to do the work for him

>> No.2453102
File: 42 KB, 512x467, graviton_garbage.png [View same] [iqdb] [saucenao] [google] [report]

All right faggots. I stayed up most the night and got all the framework in place to start writing the actual game logic. This screen cap may look like garbage, but actually a lot of code is running under the hood to make it ready to write the fun stuff. I've pushed to github the asm and a nightly build. Repo here >>2452589

I'll comment the code later more later. You can check out the SNES dev manual at:

romhacking.???/documents/226/ replace ??? with .net

If you look at the register section you will see things in my code with the same name. You may not be able to read the assembly, but you can see where I poke at things.

It's late. I'm out.

>> No.2453137

Sup OP, graphicsfag here. Before we start doing some sprites, maybe we should define what the palettes are gonna be?

>> No.2453152

I'm giving anybody who wants to do graphics free reign over theme, style, and colors for both backgrounds and sprites. Just keep in mind the sprites shouldn't be huge because I want the players to have a lot of mobility.

>> No.2453154
File: 122 KB, 500x661, 0fFIB.jpg [View same] [iqdb] [saucenao] [google] [report]

I guess I should add the reason why I say this is because most people can't code. Doing the graphics is a way others can contribute.

Oh yeah
DAY 3 ================================

>> No.2453157

Well alright, but I hope it won't be a pain to convert to actual snes colors when the time comes, what with the limited number of palettes depending on the mode used and all
Also, I was thinking of making 16x32 player sprites, will that be small enough for you?

>> No.2453246

>YY-CHR to make graphics.
Are you serius?
Use GIMP or Photoshop , index the image to 16 or 8 colors.
Then export as .pcx and use pcx2snes.

>> No.2453735
File: 25 KB, 549x513, wip.png [View same] [iqdb] [saucenao] [google] [report]

Is it possible to separate the legs and upper body of a character? Basically have a character be made of two objects : the legs as a base, and the body "following" them around. That way, we can have the legs animated while the player is moving around and have the upper body do different things (idle, attack...) at the same time without having to create a new sprite for each possible combination.

Pic is a bunch of WIP template poses. If anyone has any suggestions what the actual character design should be like, go ahead and do tell

(Also, using the legs-body technique, would it be possible to create multiple "skins" to customize your character? We'd just have to swap the upper body, that way we can have way more people contribute to the project by making their own body sprites)

>> No.2453789
File: 38 KB, 263x200, samus_costume_reference_file_by_chozoboy-d460kej.jpg [View same] [iqdb] [saucenao] [google] [report]

I think that will work. Let me mock up a level layout with some lame graphics to see.

I assume >>2453735 is yours too. That's looking pretty cool. Absolutely you can split the torso and legs into two sprites. That's exactly how Super Metroid works. You can take it a step further and layer things like arms and torsos on top of each other in a single frame of your sprite. Once again, SM does this with Samus' torso and arms, although the torso+arms is drawn as one sprite.


>> No.2453809

>You can take it a step further and layer things like arms and torsos on top of each other in a single frame of your sprite
Neat, that might be useful to give the arms some sort of bobbing animation.
Won't that be too much work on your side for such an minor feature though?

>> No.2453827

The Torso+Legs will be a tad more work, but the layering is free.

>> No.2453856

Alright, I'll get back to it then
Also, how many tiles do you think a character's sprites should have before I hit the limit? I don't wanna go overboard and exceed the snes' graphical holding capacity.

>> No.2453935
File: 278 KB, 672x900, 3UbZ8jX.jpg [View same] [iqdb] [saucenao] [google] [report]

Let me give you the OBJ (SNES sprite primitive) run down.


X=X offset (0-255 pixels)
Y=Y offset (0-255 pixels)
N=Name (tile selection, 512 tile choices)
C=Palette (palette, 8 palette choices with 16 colors each (including transparent))
P=Priority (Determines what's on top of what, 4 layers)
H=Horizontal Tile Flip
V=Vertical Tile Flip

Since you have 512 tiles you'll not exhaust graphics memory. The important things I need are your X and Y offsets and Names.

Keep in mind that X and Y in SNES land (and many consoles for that matter) is a little weird if you've never seen it. The top left is the origin with X increasing to the right and Y increasing Down.


Once you give me the X and Y offsets of your tiles in your sprite (my word for a collection of OBJs drawn together), I can add an X and Y offset to place your sprite into the game world.

If any of this is unclear, feel free to ask questions.

PS: The SNES can display up to 128 independent OBJs in a single frame.

>> No.2454098
File: 176 KB, 800x600, vr-tan.png [View same] [iqdb] [saucenao] [google] [report]

Since I had no idea what to make for a player character, I made him be Tre/vr/. That seemed appropriate after all! And he only uses 12 colors so far.

It'll take me some time to calculate the offset of each tile, give me a minute to put all the sprites together...

>> No.2454108


>> No.2454112
File: 633 KB, 1600x1558, 1378255996942[1].jpg [View same] [iqdb] [saucenao] [google] [report]

The most radical /vr/ mascot, of course!

>> No.2454123

>In this thread we come together to build a small SNES game from the bottom up.

Never gonna happen. Remember Mega Man VR? At best, you can hope for a faux SNES styled game made in Game Maker, because the average person only has the mental capacity and functionality to click on buttons to program their games. Forget about writing things down in hexadecimal, and then coming across 'whoops, the SNES 3.14Mhz CPU can't handle three objects at once' and then rewriting and redesigning the game each time.

>> No.2454181
File: 66 KB, 100x100, vr-tan animated.gif [View same] [iqdb] [saucenao] [google] [report]

Made a gif to see how it would look in motion. Does that look alright?

>> No.2454184

Looks cool. Can you may need to also tell me the timing between frames (ie how long to stay on a frame). My brother has been distracting me all afternoon so I've made little progress today.

>> No.2454192

I delayed some actions to make the gif, but basically every frame directly follows each other, except for the arms bobbing which stay up for 2 frames and down for 6.
Now I just need to rearrange the tiles and convert it to snes graphics

>> No.2454195

You may need to provide a palette too. Otherwise I can approximate the colors. Either way colors on the SNES are defined as


5 bits of RGB, with an unused 16 bit.

>> No.2454204

5 bits for a color? Is that in decimal?

>> No.2454213

By that I mean, should it be written like so:
and so on, or do I need to convert the values into something else?

>> No.2454218
File: 47 KB, 225x350, 1375883660322.jpg [View same] [iqdb] [saucenao] [google] [report]

Sorry, I'm not being very clear because I'm trying to do several things at once.

Color is defined as a 16-bit number. The bits are layed out as I wrote:


with the far right being the 0th bit and the far right being the 15th bit. So really every RGB color component has only 5-bits of information, or 2^5 = 32 possible choices. With 3 5-bit color components you have 2^15 = 32768 colors choices. The last 15th bit is unused.

If you work in the decimal range 0-100, the conversion the Red component, say, is something like: floor(decimal*32/100);

If you work in the hex range 0-255, then: floor(hex*32/255);

As long as you specify what number system you're working in and give the RGB components, I can map the color palette np.

>> No.2454220

Correction, far right is 0th bit, far _left_ 15th bit. It works like in decimal where smaller numbers are on the right. So 10000 > 00001

>> No.2454235
File: 67 KB, 750x568, 1363690370277.png [View same] [iqdb] [saucenao] [google] [report]

You might as well just go ahead and do it then, I suck at math and would probably screw something up along the way

The values are in hex and in the Blue Green Red order

Light brown : 0 124 172
Dark brown : 0 48 80

Light pink : 176 208 240

Light blue : 252 188 60
Dark blue : 248 88 0

Light red : 0 56 248
Dark red : 32 0 168

Light green : 84 216 88
Dark green : 0 184 0

Black : 8 8 8
White : 248 248 248

Background color : 204 0 216

Actual sprites coming up in a bit

>> No.2454254

Thanks, I'll do it in a bit and post the results tonight, but I've accepted that's not going to happen until I hang up on the broseph.

>> No.2454480
File: 4 KB, 128x40, vrgrid.png [View same] [iqdb] [saucenao] [google] [report]

WOW that took way more time than I thought it would
Anyway, here's all you'll need: the tiles in png and asm format as well as a text file with each tile's offset for each action and frame, ordered like this: Tile(column, row) Offset(X, Y)


Man, I really hope they had some kind of program to do that automatically back in the day

>> No.2454487

Whoops, forgot the offset for the arms when jumping:

Tile=10,2 Offset=0,7
Tile=11,2 Offset=8,7
Tile=12,2 Offset=0,15
Tile=13,2 Offset=8,15

>> No.2454615

I'm doing the palette by hand foolishly myself. I could have (and should have) written a program to do it. One of the arts of programming is knowing when to stop doing things manually and write some code. Almost done with a mock up.

Is your palette in the order you specified in your previous post, with light brown being color 0? You're going to hate me, but I forgot to say that color 0 is the transparency. In other words the magenta background should be color 0. Sorry if this causes any trouble.

>> No.2454628
File: 3 KB, 126x94, 129210262319.jpg [View same] [iqdb] [saucenao] [google] [report]

Oh shit, there's an order?
Welp, I fucked up then, I have no idea what the correct order is. How can I fix this?

>> No.2454651

Actually scratch that, I think I may have fixed it:


It now starts with magenta, and then follows the order I gave you. Well, at least I hope so...

>> No.2454697

Not hard to fix. Just reassign the first color index (0) of your palette to the color index after your last one (n). That frees up the 0 index (transparency) color. Then you have to fill in all the moved color index's pixels with the new index (n). Then fill in the background with index 0. That should work and prevent you from having to shift all your color indexes. The only downside is your palette gets slightly mixed up, but that doesn't matter.

Once again sorry about that.

>> No.2455210


>> No.2455224
File: 44 KB, 546x541, graviton_mockup.jpg [View same] [iqdb] [saucenao] [google] [report]

Mocked up the level today with some basic graphics. If anyone wants to do better, I'd be more than happy to put your graphics into the program. I also pushed the data files to github.

I'm taking a look at your sprite data right now. I'll let you know if there are any problems in the morning. I'll spend tomorrow putting together the animate sprite program and another program to animate the player. Keep tuned.

>> No.2455241

That's looking pretty sweet dude
By the way, even though the gameplay can only take place on one screen at a time, is it possible to have multiple tilesets and multiple levels?

>> No.2455248

Sure, why not. But I'll develop the engine and while others can make levels. I'll post the format when I've gotten there, but it likely will just have to be a tile map exactly like the one I've defined. I can use the tile IDs to figure out what things are and do collision detection and shit.

>> No.2455584

How does level creation work? Is it simply an array of values that define collision and tile placement?

>> No.2455654

I'm probably going to use the name table that defines the tile map. It'll serve double duty as the graphics primitive and the level data.

>> No.2455662

I didn't really understand from the decription - is this going to be a 2 player-only game? It would be too bad if people couldn't try it out on their own.

>> No.2455673

Well, coding an AI would probably take a lot more time, especially in snes assembly.
Maybe we could create some sort of 1p training mode? Like a "break the targets" stage or something?

>> No.2455680

Good fun AI is hard. That's why I'm lazy and use the meat sack sitting next to you.

>> No.2455693

I won't pretend to know how programming works, but couldn't you have something like enemies simply moving in a direction and killing you if you touch them?

>> No.2455701

On a single screen fighting game?
Seems like it would get quickly redundant.

>> No.2455703
File: 12 KB, 560x407, 1373101114196.png [View same] [iqdb] [saucenao] [google] [report]

Thanks. Honestly I made the graphics look a little ridiculous to motivate someone else to do better. I mean, wtf are fish doing floating by in the background?

>> No.2455713
File: 4 KB, 134x113, 1365758519151.jpg [View same] [iqdb] [saucenao] [google] [report]

>wtf are fish doing floating by in the background
It's original, I'll give you that
I'd be glad to contribute new tilesets if we can have multiple stages though

>> No.2455761

that's exactly what Mega Man does, only, instead of the legs being separate, it's his face to give him his blinking idle animation and different faces for attacks/getting hurt.

multiple games use that technique, good luck!

>> No.2456757
File: 45 KB, 546x541, graviton_animate.jpg [View same] [iqdb] [saucenao] [google] [report]

DAY 4 ================================

Got vrtan character set loaded, his palette sorted out, made a good portion of his sprite frames, a few animated sprite scripts, and a program to bring him to life.

He doesn't move yet, but that's coming soon.

>> No.2456760

Just use bsd

>> No.2456763

And by saying he doesn't move, I mean you can't move him around. His sprite is animated now tho. The next step is to finish off his sprite animation scripts, then step through them to make sure they work. After that I can start adding state to him to make him mobile.

>> No.2457164

I remember a couple days ago when everyone was still saying this would never work.

If I thought I could contribute in anyway I would. You should make use of the SNES graphics chip and make the background vibrant and moving (like the portals in Chrono Trigger, or the battle field for Celulux in Super Mario RPG) and leave the forground a little childish (like Yoshi's Island)

>> No.2457361

Can I made music for it? I've been sequencing on trackers and MIDI, both software and hardware, for a while now. What format would you need the music in?


>> No.2457605
File: 62 KB, 900x675, 1368317035949.jpg [View same] [iqdb] [saucenao] [google] [report]

DAY 5 =========================================

That's sick. Damn, I hate to say that right now music is outside the scope of the project for the time being. I have an audio codec written for the SNES' hardware, but I haven't completed an SPC700 assembler (the audio coprocessor), nor written a sound driver. I do have Super Metroid's sound driver disassembled, so I have a good idea what needs to be in the music code, but without a driver sounds difficult, and I won't use copyrighted code in my game. If towards the end of the project it seems sound is doable, I'll be sure to let people know. A soundless game is a little lifeless...

Also I will be on a trip until very late Tuesday. I'll try to make updates on the road if I can, but I won't have the same amount of free time that I did over the weekend. I'll continue to monitor the thread, but may only push a few new things to the github.com/gewballs/graviton repo, probably the rest of the sprite scripts.

>> No.2458371

Hey OP, your stuff's looking really impressive! Since when have you been programming?

>> No.2458423

Hater fags got quiet. This shit is looking damn good. Way to go OP.

>> No.2459243

Busy day, and computer was dead on the flight, so I didn't get anything done today. Sorry faggots.

>> No.2459265

So wait
Is /vr/ going to make a game before /v/?
This shit is blowing my mind
every god damn board has made a game except /v/

>> No.2459278

That's because /v/ is full of idiots.

>Implying /vr/ isn't

>> No.2459289

Eh, I might actually make some progress before passing out. Laptop stopped being a total little bitch. What games have the other boards put together anon? The only reason this is possible on /vr/ is because the traffic is low enough that you can have a multi week post without it getting pruned.

>> No.2459648

>what is katawa shojo
Also every game making discussion is suppose to take place outside of /v/.
I partially think it's one of the reason why /v/ is so shit.

>> No.2459713

>katawa shojo
That wasn't /v/.

>> No.2459720


fuck me, you're right! Sorry bout that,
Well they still made that relly shitty mario hack, gone homo and a doom mod about Dorner, not really games I guess.

>> No.2460285





>> No.2460318

>There's this thing called public domain.
Which has to be properly identified as so, otherwise rights automatically belong to the author. Seriously, all you you have to do is to include a readme. saying "all code is public domain" or just go with WTFPL which does exactly the same in an ironic fashion:

Version 2, December 2004

Copyright (C) 2004 Sam Hocevar <[email protected]>

Everyone is permitted to copy and distribute verbatim or modified
copies of this license document, and changing it is allowed as long
as the name is changed.



>> No.2460321

But doesn't that license forbid you from doing things you don't want to? Isn't that actually fairly restrictive?

I mean, what if I released a graphics library under the WTFPL, and some software engineer somewhere was told "Hey, ditch your shit library and use this library instead."? He'd not want to, and thus it'd be in violation of the license if he did use my code.

>> No.2460354

This is the most retarded thing I've read in a while. Do you even know how code licenses work? What it says here is I can do everything I want with MY particular copy of the code, not anyone else's copy. Do you ask your kids to play the way you want after you give 'em toys for christmas?

>> No.2460357

Yeah, and that means you CAN'T do anything you DON'T want. Like that theoretical SE, who'd be ordered to do something he didn't want to do.

>> No.2460358

Like seriously man, go check yourself for any dents on your head.

>> No.2460370
File: 20 KB, 452x339, 1408494095277.jpg [View same] [iqdb] [saucenao] [google] [report]

Ok guys , I think that I get it.
That is supposed to be a joke

>> No.2460452

No, I think they really think you literally can't do anything you don't explicitly want to do.

>> No.2460580
File: 86 KB, 500x500, 26949.jpg [View same] [iqdb] [saucenao] [google] [report]


>> No.2460631


>> No.2461737

OP here. Thanks for bumping while I was away. I'll push more updates tomorrow.

>> No.2461828

I have trouble visualizing anything that happens outside of the processor. A lot of action happens at a distance due to the huge amount of chips the console has and maybe even the cartridges.

Can you clear that up? How are the other chips programmed?


Will you ever make a thread about making games on the ps1?

>> No.2461846

>changing it is allowed as long as the name is changed.

What if I want to change it WITHOUT changing the name?

Just say "this is in the public domain" and don't bother with this ironic faggotry. This guy can't even get basic logic right.

>> No.2461879

>broad sword
My dick is broader than that.

Looks more like a gladius.

Seriously, what the fuck is up with that magazine?

>> No.2462270
File: 1.01 MB, 1000x1378, NintendoPowerVolume62Page68.jpg [View same] [iqdb] [saucenao] [google] [report]

Days of Mana was one of the coolest spreads NP ever did. I used to argue with my brother over which weapons and armor were cooler. It turned little 16x16 pixelated images into vibrant weapons and breathed a lot of life into an otherwise poorly localized (but incredibly fun) game.

Old consoles were very heavily custom hardware based, and the way to interact with hardware is to poke at registers, which are memory locations inside the supporting hardware mapped to certain addresses from the perspective of the CPU. The SNES also had an audio co-processor that was accessed in a similar manner, but could actually run code you loaded into it, but essentially it just pokes at audio registers too. Think about these registers being essentially a big board of switches that draw (sound) different things based on how you set them. I'll explain more after work today.

About the PSX, no. I have no interest in programming it. I greatly enjoy working with 3D computer graphics, but the PSX does 3D poorly (dat lack of perspective correct polygon texturing). At the end of the day though, same thing, poke at video and audio registers with the CPU.

>> No.2462460

>which are memory locations

I don't get this. You basically have a pointer that you write to repeatedly and that's how you pass/retrieve information to the other chips? That's what "poking" means? I remember there being a lot of "bus" talk but I never really understood what that was, where it is located. I don't know how to read memory maps either.

So the CPU boots and loads code starting at some address. Then the software probably sets up some basic stuff like interrupts and starts poking at the other chips in order to draw some stuff to the screen?

Sorry about the rather open ended questions, I'm trying to understand the programming from a top-down approach

>I have no interest in programming it


I was interested in modifying some of my favorite games. They're 2D though. I'm not a fan of 3D graphics, and I don't really understand anything about 3D anyway

>> No.2462520

>I was interested in modifying some of my favorite games.
Start hacking, Anon-kun. Get a hex editor and read up on some tutorials on romhacking.net. There's also a lot of custom tools there for modifying tiles and graphics editing, too. You can learn a lot by hex editing emulator save states

>> No.2462547

Yeah, but I want to modify PS1 games. Capcom's Mega Man X 4-6, specifically. People have discouraged me, telling me PS1's not for newbies. I don't really want to modify graphics, I want to modify game code and alter how it works, mechanics, controls, attacks, power ups, armors. I'd also like to modify stage layout.

I'm already a programmer and I know many languages from C to Lisp. I have a rather rudimentary notion regarding what assembly and machine code are and how it all works, processor instructions and everything, but I never really programmed any processor directly and my reverse engineering skills are lacking. I have trouble bridging the conceptual gap between hardware and software. I've been on adventures involving Linux kernel drivers but they don't seem very relevant when it comes to consoles.

It just feels so impenetrable. I just don't know what to learn, it feels like nothing comes together into a cohesive whole. I've read up on the processors but it still feels like I'm stuck, like I didn't get anywhere. The tutorials are never about what I want to do.

I want to do something like that amazing SNES Mega Man X3 hack where you can play as Zero. I don't think there'll ever be a tutorial about that. The author must have some very respectable skills.

>> No.2462578

My advice specifically applied to PS1 games. That's what I mess around with. I'm working on translating a few different games, which also involves some graphics hacking and some debugging. Only issue with CD games compared to older cartridge games is that the amount of data is larger, you have to know what you're looking for. That's where debuggers come in handy, but also save states -- which are just a dump of everything in the system's RAM.

The kinds of things you're talking about are big even for an experienced romhacker. You need to start small, mess around with Megaman 2, lots of people have done so already. It's fairly well documented; search around on the romhacking.net forums. You just have to start plugging away at it and not get discouraged. Good luck.

>> No.2463535
File: 12 KB, 420x332, shittyConsole.png [View same] [iqdb] [saucenao] [google] [report]

>You basically have a pointer to talk to other chips

More or less. You'd be surprised at how simple computers really are. The key is to understand that the majority of pins on a CPU are one of two things: address pins or data pins.

For instance, the 65816 has 24 address pins and 8 data pins. The 24 address pins, labeled A0 through A23 form a 24-bit number. These pins are used to address the full 24-bit address space of the CPU, while the data pins are used to read and or write data at the address specified. Think of memory as one big long array 2^24=16MiB bytes long. Depending on how you wire up the CPU to things, different addresses access different chips.

The easiest way to wire up the CPU would be to hook it up directly to 16MiB of RAM, each CPU address ($000000-$FFFFFF) directly 'mapping' to each RAM address ($000000-$FFFFFF). Of course when you power up your computer, RAM is cleared to zero, so it would be difficult to do anything non-trivial because you don't have a program!

A more complicated way to wire up the CPU would be to have the first 8MiB ($000000-$7FFFFF) wired to a ROM (with addresses $000000-$7FFFFF), and the higher 8MiB ($7FFFFF-$FFFFFF) wired to a RAM (with addresses $000000-$7FFFFF).

What I'm doing is making a 'memory map'. I'm assigning different CPU addresses to different types of memory. Notice that in the last example when I put address $800000 on the CPU address pins, the computer access RAM address $000000.

Other types of memories can be mapped to CPU addresses, including things like registers in video and audio DSP chips. Registers are kinda like single byte RAM addresses. This technique is called 'memory mapped I/O'.

Refer to my picture to see how one would wire up a shitty console with a 256 byte address space. The AND gates (with inverting bubble inputs) seperate the address space into 4 parts shared equally in this case between a ROM, RAM, Picture Processing Unit, and Audio Processing Unit.

>> No.2463542
File: 199 KB, 413x374, 1371147606563.png [View same] [iqdb] [saucenao] [google] [report]

>So the CPU boots and loads code starting at some address. Then the software probably sets up some basic stuff like interrupts and starts poking at the other chips in order to draw some stuff to the screen?

More or less you are right on the money. In the 65816 there are things called 'vectors' which are hardcoded locations in memory ($00:FFE0-$00:FFFF) that store pointers to the start of various kinds of code tied to specific interrupts. For instance, when powered on or reset, the 65816 accesses memory location $00:FFFC, gets a 16-bit word, appends $00 to the top to form a 24-bit address, and then jumps to that location in memory and starts executing code from there. In the SNES these values are generally wired to ROM, so they never change, although it is conceivable that they could point to RAM (although RESET really ought to point to a ROM address).

Another very important vector is the NMI interrupt. NMI stand for non-maskable interrupt, meaning the computer can't ignore it when it is asserted. On the SNES this particular interrupt is wired to the V-Blank signal on your television, which is triggered when the electron beam on old CRTs hits the bottom of the screen and needs to turn off so it can go back to the top of the screen without drawing on the screen. This period is critical for the operation of the SNES because it's the one of the only times you can write to the video registers without glitching the display.

In general an SNES program is doing two things: 1) calculating the next frame while the TV is drawing or 2) loading the next frame into the video registers during v-blank.

I know my code isn't well commented yet, but look at the githhub repository and under main.asm you'll find the game code that calculates frames and vector table, and under vector.asm you'll find the NMI routine that updates all the video registers.

>> No.2463552
File: 260 KB, 297x364, 1369932063479.png [View same] [iqdb] [saucenao] [google] [report]

>I'm already a programmer and I know many languages from C
Learn how C is mapped onto assembly. Only then will you truly understand C, and furthermore, realize C is practically portable assembly.

>It just feels so impenetrable.
No one said it's easy to pick up, but once things click, you'll kick yourself over how simple everything really is. I taught myself this stuff in late high school and early college by looking up an assembly tutorial for 6502. I had to read that fucking tutorial 100 times before I began to understand it.

Then I downloaded the SNES dev manual from romhacking.net. Once you get a passing understanding how assembly works and what the SNES (or PSX) hardware can do, you can discover how games are organized. Find your favorite game (I guess MMX) and try to understand the general structure of the code using a emulating debugger (like Geiger's Snes9x) . You'll learn a lot of neat tricks, but be prepared to dump time into your hobby.

I would strongly suggest working on a 2D system first unless you know how 3D computer graphics work (at minimum you need a solid understanding of linear algebra (vectors and matrices)).

Anyway, if you feel like your reverse engineering skills suck, tell me something specific you'd like to do, and I'll tell you how to figure shit out.

I love to hack because (as I've said in another thread) hacking is like looking at a massive cryptogram and trying to figure out what shit is doing.

>> No.2463804
File: 69 KB, 250x250, 1372711882265.png [View same] [iqdb] [saucenao] [google] [report]

Hmm, I've been trying to integrate the sprite graphic definitions you provided, but there seem to be some inconsistencies between your animation >>2454181 and your offsets/characters (for instance punch frame 2 is impossible to make like in the gif with what you gave me, although I can get close).

It's taking me a lot longer to get everything right than I thought it would because I am needing to try to piece the work together. If you could help me debug your graphics, things will move a bit faster.

Since I haven't completed the sprite definitions, no update. Expect one tomorrow night.

DAY 7 ===================================

>> No.2463808
File: 2 KB, 154x55, vrgrid.png [View same] [iqdb] [saucenao] [google] [report]

Oh yeah, this may be useful. Check out tile 0x31, you seemed to have forgotten a line on the top row. I want to get your graphics as accurate as possible. A sheet like this may help prevent bugs and characters numbered like this help me with data entry (cause that's the way they are referenced on the SNES)

>> No.2463914

I see, I'm at work right now but I'll take a closer look at it and give you correct offsets in a few hours

>> No.2463924

A little off topic, but you know what would be a really fucking interesting snes game? A snes version of smash bros.

>> No.2463950

There has been indy SNES games made.

>> No.2463962

this. what not just make a sega megadrive game?
if you're really OP and not a quitter, i want a gory shooter game that will be banned in germany.

>> No.2464165

I've thought about using mode7 to achieve the zoom effect. Sprite scaling could either be done with mipmaps or FX chip. One day anon.

>> No.2464215

I'll be at work too, so no rush. Honestly at this level of development it's exceedingly difficult to get things right the first time. I honestly would have been extremely surprised if there were no errors on the first try.

>> No.2464283

Could I get a picture of your punch frame2 so I can see what's wrong with it?

>> No.2464324

Sitting here at work and thinking that what I should have done is implemented all of the sprites and scripts, regardless of errors, and uploaded the results so it's easier to debug everything at once. You may want to hold off until I have time to do that later this evening.

>> No.2465675
File: 70 KB, 631x587, graviton_sprite_debug.jpg [View same] [iqdb] [saucenao] [google] [report]

I think we can make the deaths nasty.

Ok, so I've finished up the sprite definitions and the scripts. For debugging purposes I have scripted all unique animation frames to be in a single script, with a numeric label over the sprite to identify as described below:

00: idle.0
01: idle.1
02: idle.2
03: walk.0
04: walk.1
05: walk.2
06: walk.3
07: walk.4
08: walk.5
09: jump.0
0A: punch.0
0B: punch.1
0C: uppercut.0
0D: uppercut.1
0E: uppercut.2

Since I program, indexes are in hex and start at 0. You asked about punch.2. In my table it's labeled punch.1 and is frame 0A, so look for 0A when running the ROM. You can press start to pause or just stop the emulator.

I've updated the repo with a new graviton.smc. After we sort out the sprites, I'll start making him move.

>> No.2465683
File: 198 KB, 900x1354, 1362644893963.jpg [View same] [iqdb] [saucenao] [google] [report]

Frames 09, 0A, and 0B look kinda fucked up. 0A is in the characters, but 09 and 0B look to be offset errors. If you go over all the sprites carefully you might find other discrepeancies between your gif and what's been specified.

Also the walk body and arm scripts don't match up, and furthermore vrtan's hands aren't animated while walking in your gif, so I couldn't make sense of how those frames should look. I ended up just trying to copy the gif, but everything else is blind (except an obvious error with the tile numbers on the legs being wrong that I already fixed).

Good luck.

>> No.2465736

I can't read. punch.1 is id 0B, the one in the picture.

>> No.2465851
File: 40 KB, 477x379, 1364750258676.png [View same] [iqdb] [saucenao] [google] [report]

From what I've seen:
09's head needs to be moved one pixel to the left
0A and 0B's heads need to be moved two pixels to the left
All your 3rd arms frame (or in this case, the arm sprites from idle.2 to walk.5) need to be moved one pixel to the left
And like you said earlier, tile 0x31 needs to be moved one pixel up. Guess my hand must have slipped when I was cutting the sprites.

Otherwise, everything looks spot on!

>I think we can make the deaths nasty.
Oh boy, should I whip up some gore and ripped body parts next?

>> No.2466013
File: 64 KB, 572x554, graviton_sprite_debug2.jpg [View same] [iqdb] [saucenao] [google] [report]

Pushed the updates to the repo. Check it out and tell me if that's what you want.

Sprite 0x0A's left arm seems a little disconnected, and sprite 0x02-0x08 seem to have something weird going on by the nape of vrtan's neck.

I will need a crushing death and a spike death at least. We can worry about other ways to destroy him later when he starts getting some programming behind him.

>> No.2466278

You two are doing it up biiiig. Just her to BUMP. BUMP it UP.

>> No.2466427

Can you put the Spy Hunter tune in it?

>> No.2466479

Graphicsfag back again and this time I see what's wrong:
First, sprite 0A needs its head to be moved 1 pixel to the right, and his left arm (tiles 33 and 34) 1 pixel to our left
Second, sprites 02 to 08 are missing two tiles, 2A and 2B, that should be placed on top of the arms' tiles
I think that should be it this time

>> No.2467401
File: 105 KB, 791x829, graviton_sprite_debug3.jpg [View same] [iqdb] [saucenao] [google] [report]

Thanks for the help. I think every sprite is now pixel perfect. Checkout the amended sprites on the new version of graviton.smc that's up on github.com/gewballs/graviton .

I'm going to now produce the sprites and scripts for the horizontally mirrored and vertically mirrored graphics that are needed to make him turn left and flip upside down; you don't get those for free! I'll commit those changes and then can finally start giving him some movement.

>> No.2467424
File: 220 KB, 672x900, KI3qoaS.jpg [View same] [iqdb] [saucenao] [google] [report]

Had to make several small fixes, but _NOW_ it's pixel picture, and looks great.

Now's probably a good time to explain a bit about my code so others can read what I've posted to git hub.

First, let's start at the atom: the OBJ. See post >>2453935.
As stated, objects are specified to the SNES by supplying the following 32-bit piece of information:


OBJs actually have two more bits that specify a ninth X bit and a bit that let's you switch between the two sizes of OBJs that can be selected on a single scanline as set by register $2101 OBJSEL (a pretty obscure detail, in my program I only use 8x8pixel OBJs).

I call a cohesive collection of OBJs a sprite. This is the first abstraction that's not enforced by the hardware, but is a useful construct anyway. In my code I have a routine called Draw_Sprite (My naming from yesteryear sure does suck, but I'm more consistant now, although I haven't standardized my names yet) that you feed a pointer to a sprite, an x and y offset to add to the sprite definition. If you look in vrtan.spr you can see
some sprite definitions. For instance, look at vrtan.body.idle.r.0:

;#Data w vrtan.body.idle.r.0 {
$00 $08 $2026 $00
$08 $08 $2027 $00
$00 $10 $2028 $00
$08 $10 $2029 $00

$00 $00 $2002 $00
$08 $00 $2003 $00
$00 $08 $200A $00
$08 $08 $200B $00
$00 $10 $2012 $00
$08 $10 $2013 $00

... continued in next post...

>> No.2467426
File: 154 KB, 991x806, randi_tries_to_handle_it_by_tickletorturefever-d6pthb9.jpg [View same] [iqdb] [saucenao] [google] [report]


The first byte specifies how many OBJs there are minus one (sorry, weird convention, no need to draw a sprite with 0 OBJs).

The following lines specify the OBJ parameters. Reading one line goes like this:


where the only new things are S=OBJ size and the ninth X bit on the far right.

The next abstraction I have made are scripts, which are simply a frame count followed by a list of sprite pointers with timers specifying how long to display the associated sprite. For instance, look at vrtan.body.idle.r.script:

;#Data w vrtan.body.idle.r.script {
vrtan.body.idle.r.0 $0008
vrtan.body.idle.r.1 $0004
vrtan.body.idle.r.2 $001C
vrtan.body.idle.r.1 $0004

4 sprites in the script, followed by the pointer to the sprite, and finally a duration. Calling AnimateSprite passing a pointer to a structure that keeps tabs on the current script, frame, and timer updates the script.

When I add state to vrtan, when he's, say, idling, I simply invoke the idle script. To do something like sync his legs and body while walking, I'll have to tweak the frames for both the body and leg scripts, but that's a minor complication.

Thus, if you guys want to make animated sprites, follow this format and I can drop your sprite in instantaneously.

Of course there's room for improvement, but for such a small game, I'm not going to take the time to improve this code.

And that's about all there is to Sprites. Sexy, no?

>> No.2467791

Just checked it out, it's now exactly similar to the original sprites!

>> No.2467825
File: 13 KB, 517x541, graveyard1.png [View same] [iqdb] [saucenao] [google] [report]

This thread made me want to try out making a snes game myself, so thanks for explaining how all this stuff works

>> No.2467829



>> No.2468985


Wow thanks man for the detailed replies, you've really helped me become more confident about my understanding of things

So the memory map depends on how the hardware is wired up and thus can never change unless you change the hardware itself which would break everything. Is this part of the ABI?

The memory map is designed so that the cartridge ROM gets mapped to the address where the processor starts executing from. Right?

So the 65816 has the instruction STZ <addr> which writes zero to the absolute address <addr>. The processor just sets the pins to <addr> and the data pins to zero, and it gets written to RAM next clock cycle?

I understand the memory map in the picture and your description but I don't understand the electronic diagram you posted. I don't understand what the AND gates are doing and why they seem to be connected to the same bus lines. I think it would make sense to me if they were on different lines. The only difference between the gates seems to be the configuration of that little ball on one of its inputs. I don't understand that.

>on the SNES this particular interrupt is wired to the V-Blank signal on your television

I see people talking about this all the time and on emulator source code but I don't really understand where this comes from. I understand it's part of the TV's rendering mechanism and cycle. Does this mean the TV sends interrupt data down to the console to tell it that it just finished a vblank?

>assembly tutorial for 6502

Hey can you please post a link to it?

>> No.2469021

>I would strongly suggest working on a 2D system first unless you know how 3D computer graphics work

Yeah 2D games are my favorite kind of games, they're much easier to understand and are the kind of games I like too

>at minimum you need a solid understanding of linear algebra (vectors and matrices)

Well all I really know is high school math and physics, never had trouble with those subjects, not sure if I'm biting off more than I can chew here

I've done some graphics and game programming projects and I didn't have trouble with vectors and graphical transformation matrices.

I'd just like to post this:


Reading this was one of the most educational experiences I've ever had in my low level computing adventures

>> No.2469059

Notice how the AND gates each have a different pattern of NOTs on the wires leading into them, that makes it so that only one of those 4 chips in the diagram will be accessed at any given time depending on the value of the top 2 bits in the address bus (recall that AND requires both inputs to be 1 for it to output 1)

>> No.2469079

>Anyway, if you feel like your reverse engineering skills suck, tell me something specific you'd like to do, and I'll tell you how to figure shit out.

My focus is on Mega Man X6 for the ps1. I'm probably thinking way too big here for my current skill level but here goes:

It has some really awkward controls for certain attacks that can make you die by accident. I want to figure out how the game wires the buttons to the attacks so that I can change the control scheme to be less annoying. I suppose I should set a break point on the specific button combination and figure out what the game does? I wouldn't know what to do, though. If I changed random game code, wouldn't that break alignment everywhere?

I want to enable air dash on one of the armors. It's a pretty universal ability so maybe there's a bit I can flip somewhere that will enable it for that armor. No idea how to find something like that or even test if the theory is true.

I want to fix an oversight in the game, such as needing 5k souls in order to unlock a secret armor for a character and the plot progressing when you reach 3k souls, rendering the armor unobtainable. If I could swap those two numbers, it'd be fixed

I'd also like to edit some of the stages and enemy placement which are pretty much universally hated by everyone who played the game

If I somehow get really, really good, I'd think about implementing flight for the falcon armor. It could fly on X5 but "broke" in X6. The code exists in X5 though, maybe it could be ported


Some non-Mega Man things:

There are really interesting docs out there detailing how the Super Metroid SRAM is laid out, but they omit the structure of the map data. I'd really like to figure out how it works and maybe build a program that you can use to visualize your explored map from outside the game and even track changes to unexplored => explored status from every one of my gaming sessions. No idea how to even start here

>> No.2469085

Forgot to mention, the NOT gates are those little balls on the leads in front of the AND gates; you'll usually see them on the output end of another gate (e.g., NAND is AND with a NOT on the output end) but sometimes as in this case you'll see them on the inputs of another gate

A NOT gate by itself is usually a triangle with a ball at the output end: https://en.wikipedia.org/wiki/Logic_gate#Symbols

>> No.2469132

NAND best gate, all others need not apply.

>> No.2469213
File: 11 KB, 295x132, file.png [View same] [iqdb] [saucenao] [google] [report]


toppest fucking lmao

>> No.2469419

NOR is a universal gate too, bra

>> No.2469619

bump a bit

>> No.2470340

Yeah, well, that's just like scientific fact, man.

>> No.2471449

>this thread

not on my watch. where the fuck are you op

>> No.2471529

Godlike programmer from /g/ what do you fags need?

>> No.2471619

Super Smash Brother's SNES

>> No.2471634

We need 5 other really good programmers to accomplish this

>> No.2471848


>> No.2472172

So, modern computers have a processor, RAM, a graphics card. What the hell did retro consoles have? What's the difference between the hardware of the SNES and a computer of the time or even a modern computer?

I'm asking here due to the technically-inclined folks present.

>> No.2472373

Could we have it so the platforms randomly shift every 30 seconds or so?

>> No.2472480
File: 122 KB, 662x1000, Amano_Hill_Gigas_FFII.jpg [View same] [iqdb] [saucenao] [google] [report]

OP here. Went to visit the folks over the weekend. Unlike some of you, I have to drive 350 miles to live in my mom's basement. Internet was down, so couldn't pull my work from github, so big fat stall over the weekend.

Thanks for keeping the thread bumped. No way am I gonna let the project die before it's done. Thank god I'll have weed tonight which makes me a x10 better/faster programmer.

>> No.2473364

Damn weed slows me down a bit.

>> No.2473368

I didn't play many fighers on the SNES, but couldn't somene mod Clay Fighter or something to be more SSB?

I was less than serious in anycase.


Any updates OP?

>> No.2473369

Damn weed slows me down a bit. I got an adderral 25 today though!

>> No.2473439
File: 106 KB, 960x720, A03BnjECcAA1Tw3..jpg [View same] [iqdb] [saucenao] [google] [report]

I have laser concentration when stoned. It probably helps too that I practically learned everything I know about coding while high. To each their own I guess.

>> No.2473446

If you're anything like me getting stoned actually forces your mind to stay on one topic rather than the 700 things you can't even do anything about at the moment.

>> No.2473851

I'm the same way. I don't code much, but when I have to but I need to be stoned or I am way too distracted.

>> No.2474409
File: 2.11 MB, 3264x2448, 20150615_232852.jpg [View same] [iqdb] [saucenao] [google] [report]

All right faggots. I haven't made a player character this complicated before, so I'm winging it, but I think this is how I should plan the code for vrtan.

The picture I've attached shows more or less how vrtan will work. He will have a number of states, and transitions between those states. A simple 2D fighter may seem complicated even for simple controls, but this hammers out a lot of what is needed (I think). Now let me implement a little of it... later

>> No.2474415

Oh yeah, gfx dude. You should draw up some of the death animations if you're ok with that. I so far will program a crushing death by box, and a spike death from above and from below. Maybe there will be health, but I like the idea of trying to push people into traps.

Shit, now I want a carry state so you can grab and toss...

Well, let's do some basic walking at first. That'll take a little while anyway.

>> No.2474427

>Thanks for bumping the thread
not that guy, but you realize that sage doesn't show up in the post it's self anymore, right?

>> No.2474432

>All right faggots
>insulting the people that you are making the game for/with
this isn't /b/ or /v/, stop being a dick for no reason

>> No.2474461

If I didn't use it as a term of endearment, I doubt I would be posting at all.

>> No.2474568

>Thinks being called a faggot on 4chan is an insult

>> No.2474574

>thinks that all of 4chan is exactly the same
different boards have different cultures, using the term "faggot" that was is not a thing that is usually done on this board.

>> No.2474576

that doesn't even make sense

>> No.2474579

Chill out fag

>> No.2474596

Okay, haha, you got me.

6/10 because I legitimately didn't know you were trolling.

>> No.2475006
File: 85 KB, 601x578, graviton_grounded_testjpg.jpg [View same] [iqdb] [saucenao] [google] [report]

You guys might like today's update. I've implemented some character state framework and a first pass at a test to see if a player is on solid ground. The test is visualized with some debugging, where 0=air and 1=ground(Really stone). I'll make vrtan not moonwalk tomorrow.

>> No.2475034

Might I suggest simplifying the code by combining the crush, up and bottom spike states into a more general "death" state, and have players always dies in an explosive gory mess? Kind of like an IWBTG death, but with gibs and a blood splatter. That would require less states, less code, less sprites, and would be pretty satisfying and fun to look at

>> No.2475313

That transition diagram isn't set in stone. I'm trying to give the gfxdude flexibility and some variety, but if all I get is exploding gibs I'll roll with it. Actually I have already reduced the two spiked states into one, as can be seen in the repo under vrtan.asm, but it's pretty non committal and really just a placeholder for now.

>> No.2476637


>> No.2477065
File: 68 KB, 601x578, graviton_move_test.jpg [View same] [iqdb] [saucenao] [google] [report]

Debugged the grounded code, so now I know if the player is not supported by a floor (boxes to come later). Working on movement code that will properly restrict in the X and Y directions up to a limit.

You can jump with 'B' and toggle a hitbox with 'L'. D-Pad moves left and right. You fall when not on stone, but can jump indefinitely and jump/walk through solid stone.

This current idle state is just a placeholder to test out the Grounded and Move programs. Once I have those in place, I'll have most of what I need to implement most of the state transitions.

>> No.2477968
File: 273 KB, 560x560, 1399932490081.jpg [View same] [iqdb] [saucenao] [google] [report]

>All that progress being made
At this stage, is there still someting we can do to help out?

>> No.2478069

I still need some death animations and someone on background layout/gfx. The level I'm using won't be great for debugging, and it may not fit more developed mechanics well. A title screen would be cool too.

>> No.2478104

what about sounds, anyone taking care of those?

>> No.2478120

I've mentioned a few times now that sound is probably a no go, mainly because I don't have SPC700 ready assembler, but also I'd have to write a driver. I written a codec for the SNES A-DSP though.

Unless someone else wants to pick up that programming mantle, sound will only be added towards the end of the project if at all. I first want to meet the goals I've set out for myself before concentrating on integrating audio.


>> No.2478417

>A title screen would be cool too

A title would be cool lol

>> No.2478480 [DELETED] 
File: 279 KB, 500x375, 27391.gif [View same] [iqdb] [saucenao] [google] [report]

Working title has been Graviton, but it could be Hitler Did Nothing Wrong for all I care. If someone makes a kickass logo, I'll drop it in regardless of what it says.

>> No.2478616
File: 98 KB, 800x600, grav2.jpg [View same] [iqdb] [saucenao] [google] [report]

I noticed that you were calling it Graviton and figured it was a refference to pic related.

>> No.2478629

Source? Google just says "look up 'super hentai gifs.'"

>> No.2478656
File: 666 KB, 618x800, 1433224181357.png [View same] [iqdb] [saucenao] [google] [report]

btw, if you want to do background graphics/level design, the format is simply a 1 screen native SNES background.

For the settings that I have selected (Mode 1, background 1, 1 screen, 8x8 pixel characters, 4-bit palette), a background/level is an array of 32*32 16-bit words, each word encoded as:

msb lsb

V=Vertical character flip (1-bit, 0=disable, 1=enable)
H=Horizontal character flip (1-bit, 0=disable, 1=enable)
P=Priority (1-bit = 2^1 = 2 priorities, 0=lower, 1=higher)
C=Color palette (3-bit = 2^3 = 8 palettes)
N=Character name (10-bit = 2^10 = 1024 characters)

The array is interpreted as index 0 describing the top left tile of the screen, increasing in index as you move in the positive x-direction along the row to the top right tile of the screen at index 31. Index 32 describes the tile at the start of the next row, directly under index 0.

0------------->X // BG Screen
| 000 001 002 ... 01E 01F
| 020 021 022 ... 02E 02F
| ...
| 3E0 3E1 3E2 ... 3FE 3FF
Y 3E0 3E1 3E2 ... 3FE 3FF

I am only planning background hit detection to work on a resolution of 8x8 pixels (ie, a tile is passable of not, no partial tiles like slopes). Besides that you could draw literally a full screen of unique graphics because we aren't taxing the hardware.

WARNING: The only rules for level design are that the bottom two rows (index 0x03C0-0x03FF) effectively don't exist because they are off screen. This is a hardware limitation, as we are using a 256*239 resolution (which is 2 rows better than the more common 256*224 resolution). Also I only plan to have air, spike (just think of them as hurt tiles), and solid tiles, so nothing too complicated, but by all means feel free to make something cool.

>> No.2478659 [DELETED] 
File: 268 KB, 500x375, mWa0X.gif [View same] [iqdb] [saucenao] [google] [report]

I have no idea.

>> No.2479542
File: 169 KB, 601x578, graviton_move_bug.jpg [View same] [iqdb] [saucenao] [google] [report]

Morning update. I am finishing up the Move program, but ran out of time, however I ended up with a cool bug. I'll finish Move this evening and implement the idle, walk, and jump states.

>> No.2481193
File: 102 KB, 601x578, graviton_move_x.jpg [View same] [iqdb] [saucenao] [google] [report]

Got move X debugged (except for a strange bounce moving in the positive X sometimes, although it seems to be graphical). Took longer than I thought. Now to adapt it to Y. In this build you can toggle your hitbox size with R, as well show the hitbox with L (again).

>> No.2481508

So, we can pull from github and test it out on our emus as its being built? Cool.

>> No.2481596

Awesome thread - very interesting. The SuperFamicon was a juicy beast thanks to it's colors.

>> No.2483897

OP here. Bump. Will have updates this evening.

>> No.2484092

Sup OP, graphicsfag here. I've been busy for the last couple of days, but I'm glad to so much progress has been made already!
I'll cook up some death animations this weekend. Are crushed and spiked the only two ways to die for now?

>> No.2484458
File: 103 KB, 601x578, graviton_move.jpg [View same] [iqdb] [saucenao] [google] [report]

OP again. I've fully debugged the program that handles player movement with relation to level intersection. All of the code is at the bottom of vrtan.asm. I have commented it Move functions in (roughly) C, so it may be easier for you non-assemblyfags to read.

Hey man, that sounds great. For the time being let's keep it at crush and spike deaths. After those are implemented maybe there will be more ways to die.

>> No.2484743

bumping, and while i'm at it


is op gonna reply to these? i'm just part of the audience here but those are some interesting tangents

>> No.2484748



>> No.2484805



Not animated though?

>> No.2485367
File: 102 KB, 601x578, graviton_basic_movement_and_left_sprites.jpg [View same] [iqdb] [saucenao] [google] [report]

New update. Implemented Idle, Walk, Jump, and Fall states for both left and right directions with associated graphics and rudimentary physics.

TLDR; you could call it a platformer at this point. This is a great time to download to smc file and try it out, because it is starting to become usable. Left and right to move, X to run, B to jump, L to toggle a hitbox visualization, Start to pause, L+R+Start+Select to reset. Enjoy.

If you are interested in how I'm coding things up but don't know 65816 assembly, however have some knowledge of C, then I strongly urge you to check out the 'vrtan.asm' file at the github.com/gewballs/graviton repository. I've fully commented that document, except a small excerpt of debug code at the very top. It may be an enlightening read on how C gets mapped to assembly.

Note that my functions mainly use static storage, the stack is mainly to save subroutine return locations. This is because the stack must be under 0x2000 bytes the way the SNES' memory is mapped. Also using the direct page (which only requires one byte to address) is faster than stack based addressing, so it is preferred.

Thank you for the summary of hacking topics. I'll start to answer them in my next post after I get some rest.

>> No.2485372

New! Jumping! And to the left!

>> No.2485381

Oh yeah, final thing. Use a tab = 12 spaces to read my text documents. That is all.

>> No.2485443


I found a nice text on TV Tropes of all places.


How the fuck does this site have good writing on a technical topic

>> No.2485452

>hater faggots face when progress is being made on a game for a dead console

Such wizardry m8

>> No.2485519


Look at all those fuckin' articles, it's like a giant FAQ in prose form filled with shit I bet not even /g/ knows

>> No.2486071
File: 289 KB, 500x500, 1423102355111.gif [View same] [iqdb] [saucenao] [google] [report]

Let's go through the list...

The big difference between the two systems really boils down to the amount of memory available and what graphic and audio support chips are connected.

Given enough memory and time, an ancient CPU such as the 65816 could compute anything that a Core i7 could. Some major differences between different CPUs are the available instructions, and how wide the data and address buses are. However missing instructions can be emulated, wider data buses can be emulated serially, and wider address spaces can be emulated with a memory subsystem. The point is both are Turing complete machines, meaning that given enough resources, they can both evaluate any computable function (albeit the Core i7 many thousands of times faster!)

So that leaves the graphical and audio support chips. Through fast, specialized, commodity hardware, modern systems' graphics and audio models have converged to the simplest representation for the programmer, limiting them to only their imagination (and what's computable!). Video is more or less represented as an array of RGB values somewhere in your graphics hardware that is updated every 60Hz+, above which does not benefit the human eye. Audio is produced through your speakers by specifying the diaphragm amplitudes at 44kHz+, above which does not benefit the human ear.

Older hardware in contrast had to be cheap and powerful. Designers had to work within semiconductor fabrication limits of the day. For instance, the 65816 ran at ~3-4MHz+ over an 8-bit data bus, whereas modern Core i7s run at ~3-4GHz+ over a 64-bit+ data bus. Cheap hardware wasn't quite to the point where the modern simplicity could be realized in real time, so different compression schemes had to be invented to work with the limited time and space resources. For systems like the SNES, this involved a tiling architecture where graphics are divided up into square characters and drawn to the screen using an array called a tilemap.

>> No.2486085

>wider address spaces can be emulated with a memory subsystem
How does that work?

>> No.2486120
File: 997 KB, 500x475, 1374724384740.gif [View same] [iqdb] [saucenao] [google] [report]

The idea behind using tiles is that each time you reuse a tile, you save a bit of memory. Using tiles effectively you could make large and detailed pictures using limited hardware. Same idea with palettes. For instance, an 8x8 pixel character is 64 pixels, with a 4-bit color index depth of 16 combinations; clearly some colors must be repeated. With a palette, every time you reuse a color, you save a little bit of time and space computationally.

For audio, remember how I said 44kHz? Well the SNES had an audio coprocessor (SPC-700) that ran at 2.048MHz, and an A-DSP (Audio signal processing unit, the thing that synthesizes the digital sound signal), at 32kHz. That means the processor got 8 clocks for every sample generated over 8 voices. Clearly the SNES couldn't quite reach real time amplitude manipulation, so certain compression schemes were implemented.

The SNES used a custom format called BRR Source in the documentation. Source is to sound, as characters are to graphics. A single 9-byte source block is comprised of a 1-byte header (4-bit order of magnitude for entire block, 2-bit filter select, 2-bit scripting bits) followed by 8-bytes comprised of 16 4-bit PCM samples (Pulse Code Modulated, ie you specify the amplitude). Samples were played at a frequency and amplitude determined by a pitch register and volume register. Source blocks were strung together in long enough fashion such that the CPU could effectively manage 8 voices at 32kHz.

Something like the Genesis used a radically different approach. It used a programmable FM synthesizer as its audio DSP. Effectively the SNES played recordings of instruments, while the Genesis was an instrument. Both had their strengths and weaknesses, which for better or for worse were complementary sets.

>> No.2486135
File: 862 KB, 500x700, 1374721139269.gif [View same] [iqdb] [saucenao] [google] [report]


My point is older systems were mainly defined by their custom graphics and audio support chips. If you asked me what an SNES is, I'd point to the PPU units and the A-DSP. Everything else is the package, but those are what define what you show the world.

Extra Credit: Modern systems draw what's in a buffer every 60Hz+, even if you are still drawing to the buffer which results in graphical glitches. For this reason modern systems are 'double buffered', meaning that they have two memory arrays to display to screen. One of the arrays is displayed while the other is being calculated by your program. When your program is done, when it's time to display the next image, you switch which array is on display, and which on is hidden and ready to clear/draw to by your program without fear of graphics glitches.

On the SNES and similar older system designed for CRT use, to save on resources (double buffer = twice the memory) there is no concept screen buffer. Instead you have graphics memory and the PPU (Picture Processing Unit, ie the SNES GPU) registers to write to/read from. The system is built around the behavior of the CRT's electron beam. The beam scans from left to right across a row, turns off for a time called Horizontal or H-Blank while resetting to the left side and a little farther down, turns on again for the next scanline, ...etc..., until it hits the bottom of the screen and has to turn off for Vertical or V-Blank.

Every time a scanline is started, the PPU settings are locked in. In order to update a screen, you need to write to PPU registers during H-Blank or V-Blank, otherwise graphical glitches occur. V-Blank lasts a long time, so that's when you update your main graphics (poke at registers, update some video memory). You can also write a few bytes during the much shorter H-Blank to achieve some really neat effects will ripple on backgrounds, pseudo perspective in mode-7, color gradients, shaped windows, etc.

>> No.2486151


bank switching?

>> No.2486164

What bank do they switch to? I haven't heard any of the banks in my area having any additional address services. Is that just a rich person feature, or something? I'm using Chase right now, should I switch to Bank of America if I want my computer to use more memory? They're the only other bank in the area.

>> No.2486169

Go to bed, Ken M.

>> No.2486176
File: 112 KB, 800x770, 1429586753385.jpg [View same] [iqdb] [saucenao] [google] [report]

Btw, V-Blank is so important, that it was tied to the NMI (Non Maskable Interupt) line on the SNES's 65816. That means the SNES stops execution and services the NMI hardware vector routine every time V-blank occurs. All games you will find will generally put their update PPU code there. For a more broad perspective the NMI is one of 3 basic components of a game:

1) Calculate frame // Screen drawing
2) Wait for NMI // Screen drawing
3) NMI // V-blank

I would be extremely surprised to see variations on this basic structure in wild commercial games. Knowing this helps get your first footholds on reverse engineering a game, since you can identify how PPU registers get updated, and then how those values get chosen, whilst correlating it with visual output.

Modern memory subsystems allow a computer to access memory spaces much larger than the native processor address space. The idea is that you could use hardware to remap (or page) regions of memory as seen by the CPU. For instance, imagine a computer with a 16-bit address space. At addresses $0000-$0006 I map a 7-byte hardware register that selects and maps a 0x0100=256 byte page from a memory subsystem to CPU addresses $0100-$01FF. I've just extended the memory of the computer from 64kiB, to 4GiB+some change.

For example:
0x00000000000000 => CPU $0100-$01FF <=> RAM $0000000000000000-$00000000000000FF
0x00000000000001 => CPU $0100-$01FF <=> RAM $0000000000000100-$00000000000001FF
0x00000000000010 => CPU $0100-$01FF <=> RAM $0000000000001000-$00000000000010FF
0x00000000001337 => CPU $0100-$01FF <=> RAM $0000000000133700-$00000000001337FF

Look up paging on wikipedia for more information. Not that the SNES isn't equipped with this stuff, but in principle it could be done easily on a cart, like how coprocessors work. Just wire up the cart differently than how Nintendo specifies, not so hard.

>> No.2486818
File: 300 KB, 500x500, 1392442795562.gif [View same] [iqdb] [saucenao] [google] [report]


Ok, I've never hacked the PSX, but here is what I would do...

The first thing you want to do is map out where the interrupt vectors are for the PSX and where they point to. Next you need to find the interrupt that updates the graphics registers, it's probably a NMI (Non Maskable Interrupt). Use system documentation to map out the update routine, identifying graphics registers and where their corresponding RAM counterparts are. This will help you map out per frame things, like graphics output, but also controller I/O.

1) To fix the awkward controls I assume you just want to remap the controller rather than alter anything gameplay wise. In that case it would be trivial to hack. If you can find the subroutine that reads in the controllers (use the documentation to find the appropriate hardware registers, and a debugger to set read/write breakpoints at those addresses), then you can find where the RAM for the controllers is, then you can set read/write break points to find where the data is processed and read in for input. Finally you can edit in the address of your own function to remap the controls, find a location in memory to dump it, call it, but also call the replace function from yours, almost like it was never replaced, and now you've hacked in a controller edit hack.

2) One useful way to find state for a player is to look at save data. Saves need to be small, and when loaded into memory, target very specific parameters that often strike at the heart of player data. You can set breakpoints for addresses known to access SRAM, use the debugger to step out of the save program so that you can identify it, and reverse engineer from there. Corrupting data is a useful way to find player state too, although often times save data has checksums to verify data, so you'll need to disable any such tests by NOPing out (No Operation) assembly instructions.

>> No.2486847

Jesus, I must have been having a stroke writing part 1 of that last comment.

What I mean is find the function that processes the controller data. Find where it gets called in code. Replace that call to point to your custom function. Find some empty space to locate your custom function on the ROM, shouldn't be hard. Inside your function, you can either write an entirely new routine, or do some processing then call the function you just replaced. In this way you can insert code into a ROM image.

2) ...cont... Once you have discovered where in RAM the controls for, say, armor are, you can then set breakpoints to read and write from those addresses. Any writes will generally be from code that alter your armor. Disassemble these programs, and they may give you clues on how something in ROM gets interpreted as armor and loaded into RAM. This is what you want to edit. There is no standard way of doing this unlike with inserting code. You'll have to analyze how data is loaded and why to be able to manipulate shit. Maybe you can do it by trial and error once you know the general location, but knowing assembly makes the job easier. In the end it probably is a few bits twiddled here and there in ROM.

3) Similar to 2). If you can find the location of the 5k souls counter in RAM, you may be able to find where in ROM the data is stored. Just alter the ROM image there. Hacking sometimes just involves ingenuity with the debugger.

4) Things like enemy placement can be more challenging. Finding level data in RAM is usually trivial with a memory viewer. Once again, write breakpoints and help find where data gets loaded from. Enemy data will be related in some way, but there may be complicated header structures that use different data under different conditions and make level data variably sized and difficult to interpret. (Z3:LttP Castle during thunderstorm vs Day use same map but different enemies). Use read breakpoints to help interpret enemy data.

>> No.2486886
File: 3.36 MB, 2397x3046, 1432834883307.jpg [View same] [iqdb] [saucenao] [google] [report]

5) Adding code as complicated as a enemy requires insight into the part of the engine that controls entity behavior, and now you're getting into complicated stuff. All I'm going to say is you can insert code like I told you, but if you can do the hack, that won't be news to you.

6) SM map. Read up on SNES video registers (romhacking.net snes dev docs). Map out the NMI code (The 16-bit NMI vector at $00:FFEA points to it in bank $00). Find where video registers get updated (trace NMI, cross reference with snes dev docs). Find the associated RAM that stores the video register settings (from trace). Examining the video register settings, trace and determine which data updates the automap on BG3. Next set breakpoints for writes to the RAM address that forms the buffer for data to be sent to VRAM during the NMI. Disassembling the code that writes this data will give you a way to understand where it is stored and how it is interpreted. Even if you don't disassemble this code, you can find out where it reads data from (ie the in game representation of the automap), and you can use corruption techniques from there.

Caveat about PSX: It may be that data on disc is compressed/encrypted, which greatly complicates editing a ROM image. If so, you'd have to write an uncompress/compress routine just to even get started. Not trivial stuff for an amateur. Also PSX has a disc system, whereas SNES has full access to the entire ROM all at once. SNES is conceptually easier to understand.

>> No.2486898

Never going to happen. Just give up now already and don't waste your time.

>> No.2486905

> Adding code as complicated as a enemy requires insight into the part of the engine that controls entity behavior, and now you're getting into complicated stuff.

Enemies are a basic part of any game, you are a fucking moron.

>> No.2487234

>basic part of the game on paper
>it must be equally basic to implement and modify!
Are you the same sort of guy who thinks voice recognition doesn't work flawlessly yet because all the researchers are just stupid?

>> No.2487251 [DELETED] 

Did you even read the thread?

>> No.2487484
File: 80 KB, 601x578, graviton_hud_hitbox_cpu.jpg [View same] [iqdb] [saucenao] [google] [report]

Pushed another commit. I'm working on the HUD now. I got player score counters to work, with p1 displaying frame count and p2 movement data*.

I added a CPU usage visualization function toggled by R. It darkens the screen once the game is done processing the current frame to show you how much time it took to run the program (needless to say most of the screen is dark for such a tiny program).

Also added a hitbox visualization that show the direction of harmful tiles the player just tried to move into by turning the hit box red in the proper direction. Enable hitbox visual with L.

I changed tabs to spaces in my code, so things should be easier to read on github and more portable. I commented the main.asm fully now, and am working on standardizing the various file styles.

He is pretty much ready to start throwing punches and dying.

>> No.2487495

Oh, the * refers to this:

The movement data describes the direction the player just tried to move, and indicates if the player was unimpeded/didn't move (0), or was stopped/injured. The upper numeral is for hurt directions. The lower numeral is for solid directions. The directions are encoded as right=1, down=2, left=3, up=4. You have to do some Hex<=>Bin stuff in your head to read it, but you can cross reference with the hitbox and the new hurt direction feature.

>> No.2489389


>> No.2489517

If you guys can give me a template of some of the art you have right now, I can draw up some art for you or try to improve on what's already made.
I'll also need an explanation of the limitations and a reference picture of what things are looking like right now

>> No.2489604
File: 66 KB, 601x578, graviton_punching_fish.jpg [View same] [iqdb] [saucenao] [google] [report]

OP here.

There really isn't an art style yet besides a player sprite, which someone is working on. I put together placeholder graphics for the background. Really you can draw anything you want concerning the level. Here are the limitations for both graphically.

Objects (ie sprites) ============================
8x8 pixel character (ie tile)
4-bit color indexed pixels (16 color indexes, color index 0 always being transparent)
9-bit name (512 character choices)
8 palettes (16 colors each, 5-bit per channel RGB color)
2-bit priority (4 priority levels determine how to layer with backgrounds, not objs!!!)
Horizontal and Vertical flip of character
Can be placed independently anywhere on the screen.
Used for players.

For backgrounds ==========================
8x8 pixel character
4-bit color indexed pixels
10-bit name (512 character choices)
8 palettes (16 colors each, 5-bit per channel RGB color)
1-bit priority (2 priority levels determine how to layer with backgrounds _and_ objects)
Horizontal and Vertical flip of character
Is arranged in a tile map 32x32 tiles that fills that screen, can be scrolled as a whole.
Used for level, hud.

TLDR: You have 8x8 pixel tiles that can choose from 1 of 8 palettes with 16 colors each. Sprites can be placed anywhere (even on each other), while backgrounds span the screen as 32x32 tile images.

Practically, I have made background collision detection work on an 8x8 grid corresponding to the background screen definition. There are essentialy 3 types of game tiles planned: air, solid, and harmful tiles. These can be defined seperately in another array. The important thing while making graphics for the background is to make it work with the collision detection, even roughly.

I can you both types of graphics. Let me know what you're interested in.


Been working on the punch/uppercut, but it's not ready yet, so no update tonight.

>> No.2489742

how does the snes know the crt is in vblank and hblank?

>> No.2489772

It's driving the electron gun.
It's not a matter of knowing, it's one of telling.
Though I guess it still has to conform to NTSC standards.

>> No.2490097
File: 9 KB, 184x184, 1425259260637.jpg [View same] [iqdb] [saucenao] [google] [report]

Yes and no.

The SNES produces a NTSC (or PAL) TV signal which includes sync pulses for both H and V blank. The TV hardware locks onto these timing pulses to properly sync with the incoming signal using phase locked loops (PLLs). In other words the signal itself does not tell the electron beam where to go, just when to go, and indirectly at that.

Given the SNES generates a valid NTSC signal using hardware, certain aspects of that hardware can be integrated into the computer system. Specifically whenever the SNES generates a V-Blank, it also generates a NMI to indicate to game programs that it's time to update the registers. Knowing when to insert the blanking signals is done by internal timers. Signal timing can be read out as X, Y coordinates from certain graphics registers at any time (useful for things like the Super Scope).

// I'm not a robot, captcha

>> No.2491468
File: 3 KB, 300x85, SNESThread.png [View same] [iqdb] [saucenao] [google] [report]

ok, well here's me taking a stab at making a palette with some doodles
made some ground tiles too

let me know if anything is weird

I'm not really sure if you wanted 16 colors for one sprite or for the whole thing

>> No.2491546
File: 125 KB, 2498x1236, -VR- and his sidekick.png [View same] [iqdb] [saucenao] [google] [report]

>this thread

People on /vr/ generally know their shit. But this is beyond wizardry. How do you people learn all this stuff. I thought you had to be a nintendo engineer to know this stuff.

Are you a nintendo engineer OP

>> No.2492071
File: 71 KB, 601x578, graviton_underwater_shoryuken.jpg [View same] [iqdb] [saucenao] [google] [report]

Pushed a new version with lots of small updates tonight. First of all now the player has a punch and uppercut state. Also I implemented a double tap left or right to run. I cleaned up the HUD in preparation for more data, but feel I need to implement more mechanics before I waste time on something that isn't useful yet. I got tired of looking at the same old background, so I knocked out the walls, slowed down the fish, and added a blue gradient using constant color addition on the background and varied with HDMA (my first use of HDMA, I'm very excited actually).

Next comes adding hurtboxes to the attacks, a hurtbox visualization, and placholder spike and respawn states.

It's hard to program when I'm having fun just running this little asshole around a torus.

That's pretty weird. I'd put it in. If you want to contribute graphics, I need them in the native 4-bit SNES character format. I'd suggest using something like YY-CHR, but that's because that's all I know. Others in this thread have suggested:
>Use GIMP or Photoshop , index the image to 16 or 8 colors.
>Then export as .pcx and use pcx2snes.

Also you can have animated palette effects or swap out a modest amount of tiles on the file to achieve animation if you want. It would make things come alive.

Nope, just a faggot who can read a manual.

>> No.2492075

Double tap D-Pad left or right = Run
Attack, then Jump = Uppercut
L=Toggle hitbox visibility
R=Toggle frame cpu usage visualization

He's actually quite fun to run around (for me at least, I'm easily amused)

>> No.2492606

>It's hard to program when I'm having fun just running this little asshole around a torus.
Since the top isn't wrapped to the bottom, isn't it just a cylinder? Or is the top wrapped to the bottom and just blocked off?

>> No.2492615

The latter. Torus 4 eva.

>> No.2494339


>> No.2494805
File: 65 KB, 601x548, graviton_gradient.jpg [View same] [iqdb] [saucenao] [google] [report]

Small update this morning since I passed out last night. I wanted to learn more about HDMA, and had a great idea for visualizing gravity. I liked the gradient, so I made it controllable. Pressing up and down will flip the gradient smoothly in the background. Right now it only works on blue, but conceivably it could work on any two colors. Coupled with the gravity meter that I'll program tonight (not mechanics, just hud), it will be clear what direction gravity is pointing. I kinda want to make the plants respond to gravity too, which would be easy.

Up=bias gradient up, Down=bias gradient down

A small list of things to do off the top of my head:
spike death
entity intersection (ie boxes that move)
crushing death
player 2
(Also I want a kick attack too...)

>> No.2495035

Why would it only work on blue?

>> No.2495564


>> No.2496098
File: 110 KB, 448x750, 1357636612724.jpg [View same] [iqdb] [saucenao] [google] [report]

Short answer: 'cause that's how I programmed it.

Long answer: to perform a constant color addition (what's used to make the gradient) I have to write to register $2132 COLDATA. COLDATA is a 1-byte register that has the following form:


where B, G, and R are bits that control what color channel you're writing to (RGB), and CCCCC is the color that is written.

This register is a little quirky, in that you specify the RGB channel and data in the same byte. For instance, to write a value of 5 to Red and Green, and then 3 to Blue, you'd have to write 0x65 = 01100101 then 0x83. No other register works quite like it; others generally require you to write to an address register, then write to a data register. Also other colors registers work on data that encodes all colors in one 2-byte word.

To make the gradient work, I linearly interpolate a color from the top of the screen down to the color at the bottom (c(y)=(c1-c0)/240*y+c0, where c0 is the top color, c1 is the bottom, y is the scanline, and c(y) is the interpolated color at scanline y) . I set just the 2 colors, and then call Draw.Gradient() to fill in the middle and map it to HDMA (perscan line data transfer that, in this case, updates COLDATA during H-Blank).

I only coded up blue initially, but simple copy and paste with small modifications or a loop extend it to green and red too. Essentially if I get it working for blue, than I also get red and green for (almost) free. And then I passed out.

One cool thing is since the colors can be interpolated independently, I can fade from any one hue to any other smoothly with my code (eg blue to red). But you know what? I dig the blue.

>> No.2496103


>> No.2497106
File: 67 KB, 601x548, graviton_hud_gfx.jpg [View same] [iqdb] [saucenao] [google] [report]

Very minor update today, so no push. Rearranged BG character graphics, rotated some character colors, and added some characters for the HUD and some nice small BG animation effects I'll push with the next commit. My next goal is tie together the gravity meter, gradient change, and a few other visualizations to indicate gravity's direction. It should look pretty slick when I'm done.

>> No.2497109

Just pulled from git. Pretty sweet. What's the reason for the shift to dark background when you press down? Keep up the awesome work!

>> No.2497118

I think the gradient would be one good way to indicate the direction of gravity. I mapped up and down to change the gradient when I was debugging it. In the future the mechanics to alter gravity will be a little more indirect.

>> No.2497725


>> No.2498105

Looking good, OP.

>> No.2499143

Dude I take this and do it, but on PC, imagine graphics like another world type of feel.

OP asking for ideas but then goes with his own, why

>> No.2499179


Because he's the one making it happen. He does whatever the fuck he wants

>> No.2499429

Except he didn't go on his own. >>2454181 Tre/vr was created by graphicsfag. And while it seems to have mainly been the two of them, that seems mostly due to ambition/ability. RTFT before getting butthurt.

>> No.2499504
File: 71 KB, 601x578, graviton_gauge.jpg [View same] [iqdb] [saucenao] [google] [report]

OP here with an update and a fresh push to github. I added graphics for gauges, programmed the gravity gauge, tied the gradient to the gauge, and tied a grass animation to the gauge as well (grass droops or hangs depending on which way gravity is going). I was thinking about animating the fish when gravity changes too, but I thought it may look too busy, even though the graphics have been made.

My next task is to implement gravity effects on the player, which may take a little while because I'll have to write up new sprites for the upside down shit.

To program faster I didn't comment much stuff. I'll go back and comment stuff later when things are more finalized. Also I might write up a C equivalent program at the end of the project to make it approachable to anybody with some coding experience.

Mainly because no one else put forth a full idea. The beach idea was cool, but wasn't developed beyond a 'collect things on the beach' game. I'm talking about simple things like how are iMy main reason for not pursuing that idea is it feels very atmospheric, and without sound or music, there wouldn't be a lot of atmosphere.

Also this. But more because I have a solid understanding of the difficulty involved mapping ideas to code. It's easy for non-programmers to say they want X without knowing what they are asking for code wise.

graphicsfag has been the only contributor, and I thank him much for his vrtan (I hope he's still on board for the frag animations). Honestly I figured you guys would be more enthusiastic to help, even if it was only on ideas or graphics (wasn't expecting many coders here). I'm actually super jelly over the DOOM hacking threads. They wreck their thread and have to start a new one every other day because of too many posts.

>> No.2499505
File: 66 KB, 601x548, graviton_funky_bug.jpg [View same] [iqdb] [saucenao] [google] [report]

Oh yeah, ran into a really funky bug, but already fixed it :( . I liked this picture.

>> No.2499568

>graphicsfag (I hope he's still on board for the frag animations)
I am, don't worry. I'm sorry I haven't been making sprites as much lately, but important work's been getting in the way, and since making a sprite, cutting it and ordering the way each part works in an animation takes some time, I haven't been able to fully concentrate on that this week.

>I'm actually super jelly over the DOOM hacking threads. They wreck their thread and have to start a new one every other day because of too many posts.
Funny you should mention that, lately I've been thinking that I'd really like to see a /retro homebrew general/ happen /vr/. I mean, surely there's other anons around here with assembly/old consoles programming skills that would like to show off some projects!

>> No.2499579

Don't worry about taking time on those graphics, this is for fun, not for work. I've got plenty to program besides just watching vrtan get squished and skewered, so it's not holding up things in any way.

>> No.2499584

By the way, about the spike death, are you sure you want an animation for that? I mean, it's gonna be pretty hard to make to look like he's getting gruesomely impaled when the spikes barely go up to his ankles. I think we should go for an exploding gory death on that one.
That is, unless programming additional physics for the blood splatter and gibs is too cumbersome.

>> No.2499603

Yeah, I was also worried about the animation because of spike placement (he could land in between spikes and then what? play the same animation for landing squarely on one? That'll look good...).

I think the explodey death for spikes is just fine. I was wanting to put some gibs to bounce around just for fun too, no problem code wise. I think keeping it simple would be best, like using the same graphic for every chunk that flies out (ie how some enemies in Seiken Densetsu 3 blow up into bones, or feathers, etc. Actually both Secret of Mana and SD3 have fantastic death animations).

>> No.2499612

Shit man, let's just go all out and go full Mortal Kombat mode, where a single dude gushes out 10 gallons of blood and over 100 different limbs

>> No.2499634

So, if we can't program in snes assembly and suck at graphics, what can we offer at this stage? I like what's going on. I think it'd be cool to have stuff inside the boxes, like health ups or something when they break. But at the same time, it's kinda shitty if we all ask you to program this or that functionality into the project.

>> No.2499647
File: 73 KB, 704x476, gemma-loses-his-head-ninja-scroll-26248161-704-476.jpg [View same] [iqdb] [saucenao] [google] [report]

I guess it wouldn't be too hard to randomize what flies out (even if it's something hilarious like 3 arms) as long as number of animation frames and shit like landing behavior stays the same. Later I can always revisit parts of the code and make it more fancy once the game is nearing completion, like adding different gib behavior for chunks and arms (one splats and the other bounces).

I always felt like the SNES needed more gore and profanity. That's why I linked to Super Fucktroid in >>2450671.

Whatever comes my way I'll implement it the best way I can. For instance, I wasn't planning on an uppercut, but now you can shoryuken by sliding from Y (attack) to B (jump) on the controller.

>> No.2499663

Could you reupload Super Fucktroid? Following the link only puts me on the front page.

>> No.2499680
File: 93 KB, 1920x1200, samus-aran-metroid-game-hd-wallpaper-1920x1200-8972.jpg [View same] [iqdb] [saucenao] [google] [report]

Hmm... I'll do it one more time, but I really need to learn how to make patch files because of (c) reasons. If any body would make a binary patch file for this and upload it, I'd be much obliged.

This was just to test the SNES codec I wrote. I recorded my voice as a PWM file, encoded it, dropped it into SM where all the permanently loaded sound effects go, and then edited the data structure that points all sounds to point to the same voice data. Makes me giggle, but that's about it.

Try it again. I uploaded under the same link name.

Unrelatedly, no green makes me a sad programmer... (CAPTCH is trees *sigh*)

>> No.2499697

I see your point. Right now I have enough ideas to implement before making things more complicated. I think I have the programming covered unless someone wants to preempt me and write a sound driver. Which by consequence leaves soundfags out. Graphics are what I really could use help on because while I think I can make some kickass graphics, I need to write the program first; my graphics are placeholders to me until I get something working.

I hate to say, but I guess enjoy the slowly unfolding disaster for the time being. Even if it's difficult to contribute right now, I hope I can stimulate some of you to get more interested in hacking. I know it seems impenetrable and there's no where to begin when you first start, but it really isn't that bad. An image board isn't a very good format as a reference, but it's excellent for asking questions. So if you want to get into this shit just ask some questions; that may be the best way to contribute to the thread.

>> No.2499706
File: 49 KB, 631x469, 1334952428725.jpg [View same] [iqdb] [saucenao] [google] [report]

>Do a spin jump
Man, this is great

>> No.2499862

Awesome project.

>> No.2501406
File: 39 KB, 281x416, Bamf.jpg [View same] [iqdb] [saucenao] [google] [report]


>> No.2503691

OP bumping. Had a busy weekend and didn't get anything done. I'll post more as soon as I have it.

>> No.2504395

I can tell you're probably between the ages of 13-20.

>> No.2505386





>> No.2505457

Damn, op. I'm impressed. Can you recommend any assembly books? I'm just about finished learning c and I want to at least follow your code and ask questions. Also post manuals...

>> No.2505498
File: 51 KB, 500x376, 1435028281910.gif [View same] [iqdb] [saucenao] [google] [report]

I only recommend two books; one's nice to have (you can buy it), the other indispensable (you can download it).

(1) Programming_the_65816 by David Eyes and Ron Lichty
ISBN 0-89303-789-3

(2) SNES Development Manual

(1) is a nice reference for 65918, but not necessary to learn it. I could explain some shit in this thread or you could google it. (2) is essential in understanding the SNES hardware and how to use it. It's an official dev manual that someone leaked against trade secret agreements, and I thank them kindly. It's a little bit Engrishy, but mostly understandable.

C (and computers) in general will click much better once you understand how high level languages can be mapped to a specific machine.

I do want to point out my code is emphatically not styled after a C compiler's output, the main difference being I don't use the stack to save local variables if at all possible. I save a few cycles accessing memory by using a statically allocated scratch pad for most locals, at the cost that most of my functions aren't recursive (but they easily could be).

>> No.2505512

Thanks. I've programmed in assembly before but that was over a decade ago for the Motorola hc12. But all my assembly knowledge lived and died in the classroom.

What is your dev setup?

>> No.2505527

My setup is pretty shitty atm.

I'm running Linux, but most of my tools are Windows, so I have to use Wine. I am using a custom assembler that I wrote years ago and has several shortcomings being written by a younger me, but clearly is quite capable of generating a game. I use YY-CHR to draw makeshift graphics. I have a custom audio codec, but at the moment no SPC-700 assembler or sound driver written (although both are quite feasible by quickly hacking my assembler). I use Geiger's Snes9x debugging emulator to run games and examine memory (super useful). I use vi to edit.

I have a better assembler designed, just not implemented yet. I have been hesitating to write a game for a while until I could get my more powerful assembler working (rivals gnu assembler in functionality), but got the itch bad so I started this project.

>> No.2505546

Why not run Windows in a VM?

Hopefully, when you start the next game, if its written in c, I will be able to contribute. This thread and the work you've put in so far is truly inspiring.

>> No.2505590

Works fine with Wine. I just wish the emulator was for Linux. One day I'll write my own.

I have commented some of the assembly in pseudo C already, and will fully comment the game once everything is complete. I have no plans to develop a C compiler for 65816 though, even as a gcc backend, as I could do better by hand due to the vast number of addressing modes available on both the 65816 and SPC-700 and small number of registers. Plus I actually like writing assembly in this context. Also I've learned many techniques by reverse engineering code, which is only possible if you can read teh asm.

I might write up a _very_ brief overview of 65816 assembly over a few posts soon. It would need to cover architecture, addressing modes, and operations.

>> No.2506016
File: 70 KB, 601x578, graviton_antigravity.jpg [View same] [iqdb] [saucenao] [google] [report]

OP here.

So I got off my potless ass and programmed the inverted sprites and rudimentary antigravity. It's starting to look pretty good, and the antigravity mechanic is bound to be make things confusing, hectic, and (hopefully) fun. Check out the smc file and (uncommented) source assembly code at:


Next on the agenda... spikey death => dead => respawn player states. Then player/box interactions. Then squish death. Then hurtboxes. Then two player. The random shit like a title, credits, and polish.

>> No.2506603
File: 28 KB, 563x400, image.jpg [View same] [iqdb] [saucenao] [google] [report]

Oh shit vr/tan is upside down. Gonna pull when I get home tonight. And smoke some of that loud.

>> No.2506652

A few observations:

>For some reason the bottom is cut-off on my display no matter what resolution I try it with.

>You should make the boxes move with gravity as well as /vr/tan

>Are you SURE it would be to hard too do some sound? Just a jump and punch sound effect would be a game changer.

>> No.2506694

Went home for lunch and gave this a pull. Looking good. Had a lot of fun controlling him with just gravity no jumps. Here's my observations / questions.
>What are L & R doing, is that just debugging. The green box around /vr/tan and R seems to make 90% of the screen shaded.
>Are uppercuts functional? I thought I read that earlier in thread. B/c I cant seem to get /vr/tan to uppercut
>It seems like the gravitiy is on/reverse, but the red boxes make it look like their will be states / levels of gravity... Is that so?
Shit looks real good OP.

>> No.2506702

Op, how old are you ?
Is there anything we can help ?

>> No.2507156

OP is underage, b&

>> No.2507181 [DELETED] 

Writing in assembly can become strangely kind of addictive. Sometimes the problems you run into are interesting, like puzzles. However I don't really see the point of writing with it in this day and age tbh, apart from the attention. Make a nice game on windows.

>> No.2507185

Writing in assembly can become strangely kind of addictive. Sometimes the problems you run into are interesting, like puzzles. However I don't really see the point of writing with it in this day and age tbh, apart from the attention. Make a nice game for windows. The tools will be so high level that you'll get to focus on the actual game design, not under immense stress trying to get it to work and hoping it all comes together.

>> No.2507190

it's not as fun to write a game for windows.

besides, the world doesn't need another Unity pseudo-retro indie game

>> No.2507665
File: 140 KB, 560x570, 1434901897755.jpg [View same] [iqdb] [saucenao] [google] [report]

1) Your emulator sucks. I'm using a hardware setting called overscan that increases the resolution I'm using from 256x224 to 256x239, adding two more tiles along the bottom row. I did this to increase the size of the playfield. Additionally I get some more time to calculate a frame, however I get less time to update the graphics during NMI. If you're emulator can't handle the awesomeness, I'm sorry.

2) Boxes will definitely move with gravity, and even squish unsuspecting players.

3) I'm tempted to do sound, but that's literally the last thing I'd do for this game if it's to be done at all. I first want a working game. Then I can add a _primitive_ sound engine later.

L shows vrtan's hitbox used for both background intersection and hurtbox intersection (although many games split these concepts into two hitboxes). R darkens the screen at the point when the next frame's calculation is done; everything in the darkened area is time spent waiting for the NMI, the time only safe time to update all the graphics registers. It helps to visualize how CPU intensive the game is. If ever the darkened area gets to the bottom, my game would skip an NMI update so it could finish calculating the next frame, effectively halving the frame rate.

Uppercuts are activated by pressing punch (Y) and then jump (B) during the punching animation. Try sliding from Y to B on your controller.

I haven't decided exactly how the gravity mechanic will work yet. Currently the player falls at a constant velocity (no acceleration). It could be that gravity gets weaker when the gauge gets close to zero, or that it is a visualization showing how close things are to flip. I have a lot of freedom programming the logic now that the gauge and antigravity are more or less in place.

Old enough to have grown up with the NES and SNES. If you can't code or draw graphics, ask questions about what I'm doing to make the thread more interesting than just me updating.

>> No.2507673


I wish I had these skills when I was underaged. No one to teach me and no equipment to learn on.

I only write assembly for consoles (and if need be a compy). I respect and love my compiler, even more so now that I've gone through the trials and tribulations of manually transcribing assembly to machine code. Assembly should only be invoked in a modern context to poke at instructions that don't map to portable commands, like processor flags, MMX, SSE, etc.

That said I like to know what my code is doing. Too much bloated shit code out there. I like building from the ground up because I'm responsible for everything, the fewer black boxes the better.

Agreed x2

>> No.2507735

>Your emulator sucks

Thanks, asshole. You also could have just said what shit tier non-native resolution you're using instead of going on a rant about what emulator you use. My bad for using Snes9x

You never said what emulator you use either.

>> No.2507754

Dude, don't get so bent out of shape, I wasn't trying to offend, just being silly. My emulator on my phone can't do overscan either. Snes9x should be able to handle it though, as I use Gieger's Snes9x debugger as I have mentioned in this thread.

>> No.2507772 [DELETED] 

Fuck off already, tripfag.

>> No.2507803

Do not reply to tripfags.

>> No.2507898

>emulator can't handle something
>its shit tier and non-native


>> No.2507918

Will it have RPG elements?

>> No.2508348

You know those elements in an RPG where you move the character around the screen. It will have those.

>> No.2510104
File: 70 KB, 601x578, graviton_boxes.jpg [View same] [iqdb] [saucenao] [google] [report]

OP here. Still draggin' my feet without mah little green gerbils. If any of you faggots live in the NC triangle, and are into that shit, you should let me know.

I've converted the boxes from background tiles to sprites that are influenced by gravity. They fall up and down with vrtan, but I haven't programmed vrtan-box interactions yet, so they pass through each other. If you press R you can see the CPU usage visualization, and you can see I'm starting to use a sizeable chunk of time. I'm sure the full game will be fast enough optimization (which it could use a lot of).

Baby steps, but at least the progress is steady.

>> No.2510106

*without* optimization.

>> No.2510604

OP is a pretty cool guy

>> No.2511427
File: 1.51 MB, 3264x2448, image.jpg [View same] [iqdb] [saucenao] [google] [report]


>> No.2511793

>Whaaaa! I don't know what I'm doing so you're an asshole

>> No.2513428


snes9x even has a SPECIFIC OPTION to enable overscan.
Options -> Preferences -> Display -> Use overscanned height

Unbelievable incompetence.

>> No.2514930


Never has a tripfaggot never been so BTFO before

>> No.2514953

My pitch:

The cast of Reno 911 in space.

>> No.2515413

My pitch: SotN ripoff on a 16 bit system

>> No.2515467

>we should consider a non-scrolling type game
Taito produced some really great single-screen arcade style platformers in the day. A static shmup might work too. Like say, Galaga '88. Two player co-op would be nice.

>game ideas
Feel free to steal my Gravnic spin-off. You just use the d-pad to shift movable objects in the cardinal directions. There's a match-3 mechanic for fruit pieces, keys and locks and other little doodads. The good thing about puzzle games is that they're easy to prototype -- level design eats up the bulk of development time.

Additionally, this music is free to use if you decide to implement sound. I'll be happy to rework the samples, arrangement, etc. I'm uncertain about the particulars, but there is an IT->SPC conversion tool out there.

>> No.2515763

We should do a Sony Snes CD game

>> No.2516441


Did you read any of the thread or just comment right away.

>> No.2516448

Just commented right away :^)

>> No.2519273

OP here.
Between trying to find a new place to live and driving out of state for the 4th, had no time to work on programming. I did manage to get a bag of motivation, so things should start moving quickly again.

I'll try not to bump without updates for the rest of the dev.

>> No.2520253

I went to your state for the 4th. Oak Island.

>> No.2520506

He wrote an entire paragraph about how much my emulator sucks because I evidently missed the part of the thread where he said he was using a non-native resolution. Yes, he's an asshole.

More example of being an asshole. My bad for not blindly checking boxes when every other game I've emulated since 1999 has worked without that "option" enabled.

You mean not at all....?

>> No.2520738

You expect us to believe you were emulating at the age of 1? Because you sure don't act like an adult.

>> No.2521119

Totse Sux. Just be a fucking anon. Are you special? Posting your shit all over with a needless trip. GTFO or be anon. Also be less of a whiny bitch.

>> No.2522498
File: 12 KB, 570x402, crushed1.png [View same] [iqdb] [saucenao] [google] [report]

>I did manage to get a bag of motivation, so things should start moving quickly again.
You lucky bastard. My delivery dude's been MIA for over a week now, shit sucks.
But somehow, I still managed to get off my lazy ass and start working on some sprites again. Expect more new stuff later today!

>> No.2523307

You've been emulating SNES games since 1999 and you have never heard of overscan before? This is an impressive level of stupid. Did you practice, or were you born that way?

>> No.2523319
File: 75 KB, 632x453, graviton_palette.jpg [View same] [iqdb] [saucenao] [google] [report]

Awesome man, looking forward to the new graphics.

Please use the palette I've included in this picture as a color guide. Feel free to change the 3 magenta colors. If you follow this color ordering things will be much easier to integrate. Note color 0 is transparent, and can't be redefined; don't use it for black.

I'm working on player box interactions from the players perspective. Boxes can't move the player, but they will support him. After I get this integrated I'll move on to making the boxes move and hurt vrtan.

Btw I'll have to make a credits screen. If you want something to be in it, just upload it with your artwork sometime.

>> No.2523331

Just ignore this guy. He's a troll or a dumbass.

Fun fact, the SNES has 6 resolutions:
256x244 : Mode 0-4,7
256x239 : Mode 0-4,7 with overscan
512x224 : Mode 5,6
512x239 : Mode 5,6 with overscan
512x448 : Mode 5,6 interlaced
512x478 : Mode 5,6 interlaced with overscan

And non of the are any more 'native' than the others.

>> No.2523334

Ignore the tripfag that is, not you >>2523307.

>> No.2523456

Whoa, I kinda mistyped. Don't worry about the transparent at color index 0. If you use the same tools as you did last time, it automatically makes the transparent color 0. In other words, the palette you can define in your program is color index 1 whether you know it or not.

>> No.2523984
File: 31 KB, 178x238, crushedanim.gif [View same] [iqdb] [saucenao] [google] [report]

Sorry about the delay, I had to tale a small nap. But it's done! Here's a little preview of how it should look in motion.

>> No.2523985
File: 2 KB, 169x51, crushedsprites.png [View same] [iqdb] [saucenao] [google] [report]

And here are the actual sprites. Now I just need to convert them to SNES graphics format and they should be ready to use.

>> No.2524128
File: 75 KB, 301x267, 1435548414094.png [View same] [iqdb] [saucenao] [google] [report]

OP here.

Dude, that's fucking sick! I love it. Be sure to use the palette guide I posted >>2523319 when converting to SNES format. Also when defining the X and Y coordinates, use the top left corner of a walking frame as the origin if possible.

Looking forward to adding in the squish state. I've been kicking around how I want to do general hitbox collision with the boxes, but the problem is a little tricky on a torus, and I am still working on it. I'll post results as soon as I get them.

>> No.2524357


>> No.2524606
File: 40 KB, 693x554, Capture.png [View same] [iqdb] [saucenao] [google] [report]

Done! I even used YY-CHR, since that's what you're using, so no need for additional recoloring or stuff, and you can just open it up and use it straight away!
Coordinates coming later

>> No.2524661

What a cool fucking thread.

>> No.2524682

Ain't it? Oh my gosh, I wanna try out you and the other anon's game when it's done, OP.

>> No.2524941
File: 22 KB, 396x286, 1434513759421..jpg [View same] [iqdb] [saucenao] [google] [report]

Just a heads up, the hardware can only mirror characters horizontally and vertically, it can't do rotations. I noticed in your gif gibs spinning around. If you want that effect, you'll need to add graphics of the gibs at a 90' angle to the originals. This only doubles the amount of characters, not quadruples, because we can still take advantage of the H and V mirroring.

>> No.2525142

Not him, but can the hardware mirror diagonally? If so, then instead of spinning around the gibs (requiring 2 characters, and 4 different "shapes" with mirroring), you have one character, and flip it diagonally rapidly to give the impression of a spinning gib while saving an extra space for another character.

>> No.2525523

You can set the horizontal and vertical flips separately, meaning you can combine them to get a diagonal flip.

Thus you could either use 2 (rotated) characters to make 4 frames of animation, or 1 (diagonal) character to make 2 frames of animation.

This is a clever way to save memory. That's the kind of thought that had to go into old video games. That's also why I love this old stuff.

Since memory isn't an issue yet (I haven't even filled a 32768 byte SNES bank!), it'd be easier to do 4 frames of rotation because graphics guy doesn't have to redraw diagonal gibs.

>> No.2525570

Eh, disregard this. I drew it out and combining H and V flip isn't a diagonal flip. And even if you had the diagonal flip, you could still only do 2 frames.

>> No.2526535

Try it out now. It's fun being a tester plus we can help OP by giving comments and critiques of gameplay. Check his github and.

>> No.2528169
File: 195 KB, 804x720, 1434343274776.jpg [View same] [iqdb] [saucenao] [google] [report]

OP here

Finally got an _extremely_ general and fast hitbox vs hitbox movement code on a torus. I was having trouble with the concepts and assembly, and after several attempts at writing and revising a C program, I finally hit on how this needs to be done.

The purpose of this code is to take a hitbox of width 'wx' at position 'x0' and move it 'dx' to a new position 'x1' under the constraint that it can't pass through a list 'box' of 'boxCount' impassible hit boxes.

This code works on a 0x0100 pixel torus. It can easily be made to work on torii with resolutions of any power of 2 using logical and (&), or any size if one is willing to use (expensive) division instead.

word MoveBoxX(word x0, word dx, word wx, box_t box, word boxCount){
__word x1; // New hitbox x
__word xa; // Hitbox left
__word xb; // Hitbox right
__word bw; // Stop box width
__word ba; // Stop box left
__word bb; // Stop box right
________(bw>=wx)&&( // Stopping box wider
__________(bb>=ba)&&(ba<=xa&&xa<=bb || ba<=xb&&xb<=bb)||
__________(bb< ba)&&(ba<=xa||xa<=bb || ba<=xb||xb<=bb)
________(bw< wx)&&( // Hitbox wider
__________(xb>=xa)&&(xa<=ba&&ba<=xb || xa<=bb&&bb<=xb)||
__________(xb< xa)&&(xa<=ba||ba<=xb || xa<=bb||bb<=xb)
__return x1;

>> No.2530329


>> No.2532397


>> No.2532402

Does this mean that anything that crosses the 256 pixel boundary on either side will automatically wrap around? That is very clever.

What about the lines "bw=box.w;" and "ba=box.x;"?
Do they not have the "%0x00FF" because they are guaranteed to be within bounds?

>> No.2533958
File: 73 KB, 601x605, graviton_mob_intersection.jpg [View same] [iqdb] [saucenao] [google] [report]

Finally an update. Debugged code:

word x0; // Initial position
word dx; // Delta position
word xw; // Move box width
word x1; // Final position
word xa; // Move box left
word xb; // Move box right
word ba; // Block box left(top)
word bb; // Block box right(bottom)
word bw; // Block box width
word box.n; // Crate max index
word box.wx[]; // Crate width
word box.x; // Crate position

void MoveMob(){

void MoveMobX(){
______if(!MoveIntersectY(yw)) continue;
______if(!MoveIntersectX(dx)) continue;
______if(dx<0) A=xa, Y=xb, xa=Y, xb=A;
____________if(A<0) A+=0x0100;
____________if(A>=0) A-=0x0100;

bool MoveInIntervalX(){
___return (xb>=xa)&&(xa<=x1&&x1<=xb) || (xb<xa)&&(xa<=x1||x1<=xb) ?1:0;

bool MoveIntersectX(A){
___return (
_________(bb>=ba)&&( (ba<=xa&&xa<=bb) || (ba<=xb&&xb<=bb) )||
_________(bb< ba)&&( (ba<=xa||xa<=bb) || (ba<=xb||xb<=bb) )
_________(xb>=xa)&&( (xa<=ba&&ba<=xb) || (xa<=bb&&bb<=xb) )||
_________(xb< xa)&&( (xa<=ba||ba<=xb) || (xa<=bb||bb<=xb) )

Right both times.

>> No.2533979
File: 73 KB, 601x605, graviton_protosquish.jpg [View same] [iqdb] [saucenao] [google] [report]

Got mob-mob movement intersection working. Mobs can support each other, but not push each other.

I also took gfxguy's squish graphics and integrated them into the existing tile set, defined sprites and animation scripts, and added crush and respawn states to vrtan. Currently the crush state is activated by pressing X; you die, disappear, then respawn at a random (sometimes solid) location. It shouldn't be too much harder to make the crates crush vrtan. Currently gibs do not fly.

Making the crates push and pull vrtan makes me think it would be a lot of fun the other way around too, that is I think the players should be able to kick crates around somehow. I'll get the basic crush and push functionality for crates working in Y, and then see what I can do about moving the crates in X.

Jesus that took a while to program correctly. I learned a few things, and know I could probably make it a little more efficient, but shit's done, and I have a good and general solution that's probably a little too powerful for what it's being used for.

Btw this boards been really fast lately...

>> No.2534183
File: 2.36 MB, 758x716, jump_gravity_punch_uppercut_die.webm [View same] [iqdb] [saucenao] [google] [report]

Awesome. I just pulled the smc from your git. Digging the death scene. webm related, little bit of the gameplay so far for anyone out there who hasn't given it a shot and wants to see.

>> No.2534316

You can run too by double tapping a direction. I dig the video. I've been meaning to learn how to make one.

>> No.2534380

Running is cool, really dig how this is coming along. I'm an applefag so I used QT to make a screen recording then used http://www.online-convert.com/ to convert to webm.

>> No.2537439
File: 14 KB, 641x480, ABL.png [View same] [iqdb] [saucenao] [google] [report]

I can do your sound effects, OP. Just write a list of what SFX you would need to make the game decent.

I did the sound for this game called AliceBitLand I'm working on with an ex of mine.

>> No.2538895

That's awfully pretty. Where is it from?

>> No.2539182
File: 59 KB, 250x271, spaceghost2.jpg [View same] [iqdb] [saucenao] [google] [report]

Hey OP, graphicsfag here. Sorry I haven't been around during the past week, but my freaking computer's power supply shat the bed and I haven't been able to fix it myself!
Fortunately, I went to visit my old folks for french national day, and I snagged my older laptop back from the attic while I was at it, so I can at least do simple stuff while waiting to buy a new one.

I see you've been converting and ordering the sprites yourself in the meantime. Hope that wasn't too much of a pain to do all alone... Is there anything else that you might need now that the player's pretty much done?

>> No.2539274

Pretty cool!

>> No.2540670
File: 71 KB, 601x578, graviton_gibs.jpg [View same] [iqdb] [saucenao] [google] [report]

Both a major and minor update.

So as soon as I got player-background and player-mob collision detection going (which was a major achievement), I ripped up what I had and reimplemented moved from 8bit integers to 16bit fixed point numbers. This is a major update because now I can implement much more fine tuned physics.

I also added some code to run particle-like objects so I can spawn gibs and have them run their own code. Press X and watch vrtan explode into gibs (influenced by gravity!). I will implement other particles, like dust from landing crates.

These sprites were easy to figure out. The last ones were more difficult because of the overlapped sprites. If you want to make anything else, I think a flying kick animation would be bad ass, as well as a crate pick up animation (think Super Mario Bros 2). Other than that, you should send me something to put into some credits, be it a graphic, handle, phrase, etc.

I'll consider putting together a sound engine since so many people have asked if they can contribute audio. Let me come up with a specification over the next few days. If you guys can follow it to the letter, then there will be a much higher chance of getting sound in this project.

>> No.2540673

Of note, the gibs don't bounce because that'd eat up a lot of CPU time (view with R button), although they very well could. Also note that they fade away. I actually blink them such that half are on and half are off, letting me seemingly draw twice the gibs with next to no overhead. Neat trick.

>> No.2541182

Nice exploding death scene.

>> No.2541842

Is anyone her familiar with 6502 asm?
I'm having trouble finding the best assembler for nes, because most guides use different assemblers

>> No.2542071

OP here.

If you can't tell, I'm doing all the programming. Knowing 65816, by extension I know 6502. Feel free to ask anything if you have questions.

I wasn't happy with the state of assemblers when I started hacking years ago, so I programmed my own. In retrospect I recognize it has its limitations, but clearly I can develop a non-trivial program with it. Sorry, I don't have any suggestions for assemblers available online.

>> No.2543467

According to the nesdev forum asm6 is the newest/"best" assembler for nes 6502
The problem is that most tutorials are written for NESASM and won't work with asm6

>> No.2545038
File: 84 KB, 601x571, graviton_edit.jpg [View same] [iqdb] [saucenao] [google] [report]

Added a basic in game level editor.

Select=toggles edit mode.
D-Pad=Move cursor.
A=Place tile
Y=Cycle forward through characters
B=Cycle backwards through characters
X=Cycle through the 4 flipping modes (~,H,V,HV)
R=Cycle through the 8 palettes
L=Cycle through the 2 background-object priority states

Press select. A cursor will appear in the top left corner.
Use the d-pad to move . Inside the cursor you'll see a preview of what you are placing. Note the SNES's objects and backgrounds do not share palettes, so not all all palettes are available. However I have set the default to a value that shouldn't need to be changed. I've also set the default character to a block, one of the only solid tiles. I need to implement a hud so you can see what's selected, but for the time being I wired (most of) the character number to player 2's score. The tiles that are important are:

0x20 Stone
0x21 Spike
0x22-0x25 Grass
0x26-9x27 Grassy stone
0x28 Air (or any clear tile really (or really anything else not stone))

Unfortunately the blocks can't be moved around in edit mode yet. You can however watch them fall continuously by deleting the floor out from underneath them.

Everything pushed to github. Just added edit.asm. Last time was move.asm, and that is fully commented for those interested and that can read C.

Try to make some levels and I'll add them in.

>> No.2546874

Thanks for commenting the code.

>> No.2548705
File: 13 KB, 601x571, graviton_move_bug2jpg.png [View same] [iqdb] [saucenao] [google] [report]

Np. I'll fully comment it when I'm done.

So fast collision for moving mobs is hard guys, but I think I'm zeroing in on a solution that is very general.

My original approach involved moving the player against all crates, modifying the resulting dx and dy but retaining the initial position, and then moving player against the level. For fast calculation, the movement is first calculated in X or Y, then Y or X, depending on the relative magnitude of the displacements.

This introduced a subtle bug where the player could be sliding down a wall and end up standing on a crate embedded flush (image). This is caused if the X velocity exceeds the Y. If the player is immediately above the crate in Y then he will be moved in X unimpeded, and stopped in Y when moved down by gravity and intersects the crate. This zeros dy. Then starting back at the initial position, the player is moved against the background, stopped in the X direction, and dx is zeroed. Thus the player's velocity is zeroed, and they don't fall. Another problem is the current code also doesn't generalize to more than the player and crates.

One reason I started this project was to try to solve serious collision quickly for a larger scale game, so I'm trying to design a good solution.

Here's what I'm thinking so far. When moving a mob (including the player), it is moved first in the direction that has the greatest displacement, then the other (like before). The mob is moved against both the background and other mobs in the first direction before going on to the second (unlike before). When the moving mob intersects other mobs, those mobs return a pointer to their data. The moving mob then has it's own program to decide how to interact with the intersecting mob based on identifying the mob pointed to and modifying both mobs' states if needed. Movement priority is governed by where in the list a mob is processed (unfortunately).

I hate introducing priority, but need to be fast.

>> No.2549135 [DELETED] 
File: 14 KB, 506x504, Capture2.png [View same] [iqdb] [saucenao] [google] [report]

I still c

>> No.2549138
File: 14 KB, 506x504, Capture2.png [View same] [iqdb] [saucenao] [google] [report]

I still can't believe you managed to cram a freaking level editor in there
How do you plan to implement all the user made levels?

>> No.2549250

Love your thread - is the mob nomenclature borrowed from Doom?

>> No.2549576

Sram sharing?

>> No.2549578

>is the mob nomenclature borrowed from Doom?
Nah, didn't lift it from Doom, and the word mob as used in video games probably predates any usage in Doom (which I was unaware of). I like short non abbreviated names, and mob is shorter and more specific than object or entity.

Btw guys, I'm on a trip through Friday this week, so updates will be slow. At the very least I'll get vrtan to squish due to crates, even if it ignores some buggy behavior to pull it off.

>> No.2551806

daily bump

>> No.2553973

>daily bump

>> No.2554023
File: 347 KB, 1024x600, graviton_shitty_spike.png [View same] [iqdb] [saucenao] [google] [report]

Thanks for the vigilance guys. I watch this thread like a hawk, but it's good to know lurkers got my back.

So programming on the road is virtually impossible. My laptop sucks, and I can't run my debugging emulator, which makes things a million times harder to debug.

Regardless, I did implement spike death. It's a very modest commit, done in a very hackish and temporary way, but it works. Actually I said I would do crush deaths, but accidentally did spikes tonight (however that happens).

I'll implement crush deaths tomorrow. Stay tuned.

>> No.2555301

Goddamn it, between the SNES Play Station, Iwata dying, Reddit partially imploding, etc, this board has turned to quicksand. Bump this shit.

>> No.2555902
File: 419 KB, 641x641, image.jpg [View same] [iqdb] [saucenao] [google] [report]

Bump it up.

>> No.2556582

Super Smash bros, with every playavle SNES "2d view up/down, front/back" character that can attack and is from nintendo

>> No.2556605

To make more specific.
The game is a fighting game.
It will have ALL characters that fit on those rules:
1-Is from nintendo
2-Not based on movies and etc..
3-Its from snes
4-Can attack
5-Can Jump
6-Can to backward
7-The game the character is on is a 2d view game
7.1-There are 3 types of 2d view games depending of the 2 axies you use, the one I am talking about is the one with up/down axies and foward/backward axies, one example is mario.

Characters would be exactly like they are.

The game would have a ratio system, less powerfull character have a HIGHER ratio.
The ratio means the amount of battles the char need to lose to lose the match.
Imagine player A select a ratio 1 character and player B select a ratio 4 character. The game start and Player B lose, the game will continue since player B is ratio 4. A new battle continue with same chars and player A lose, since he has a ratio 1 he loses the game.

So in the end it will be like a best of X match, where you cant change your characters between matches and the ratio of your character dictate the amount of times you can lose.

Gameplay is like usual fighting game and not like brawl, you lose your life to win.
Characters are exactly like in the original game, and on some games character have stocks like mario, those specific characters will need to lose all their stocks to lose a match.

>> No.2556935

How do you get to the level editor? I downloaded the latest update but don't see level editor option.

>> No.2557017


>> No.2557027

RPG adventure game with both top down world exploration and 2D platforming elements. Fantasy type setting.

>> No.2557107

Did something actually get made?

>> No.2557116

I should have read the thread first.
Holy shit I'm impressed, OP really knows his shit.

>> No.2557168

You seem to know a lot and I probably should ask this somewhere else but where do I learn more about computers?
I know python and started learning C and have learned some stuff but I don't know very well what virtual memory, stack and those kind of things are.
For example if I wanted to program in assembly I'd be lost because I don't know about memory or the stack.
I'm not asking you to explain such a complex topic to me because you certainly have better things to do with your time but which books did you read to learn that and the rest of the stuff you know?

>> No.2557194

This is OP. I'm still only trip, and can't answer more fully until Friday, but learning C and how C programs compile is incredibly illuminating and equips you to understand how computers work. Python is great, but it's a black box that gives you insight into programming but not computers, if that makes any sense. Feel free to ask questions until I get a chance to answer; that's partially what I made this thread for.

>> No.2557235

I know what you mean about python abstracting a lot of stuff.
What I'm looking for is a book or site that talks about everything from the beginning, memory, virtual memory, stack and certainly related stuff I don't even know the name to.
I end up trying to learn stuff I don't have the knowledge to, and I want a book so I can learn things in the right order.
What did you use?

>> No.2557320

ZSNES? For all your knowledge of programming you certainly don't know much about emulation. Don't test your project on the most terrible emulator software available.

>> No.2557376

This. ZSNES has a horrible GUI.

>> No.2557384

What the fuck does the gui have to do with anything? Also I like the gui.

>> No.2557470

>>2557235 it's me
I found a book called computer architecture a quantitative approach, do you know it?

>> No.2557537

OP again.
Watch these lectures on computer organization (maybe start on lecture 4)


I found these to be of extremely high quality, although the class moves fast. This series goes over everything you want to know. Look for text books on Computer Organization for something you can hold. Don't have my bookshelf next to me atm, but I can suggest specific books when I get home Friday.

You have sharp eyes. You also picked the only image on the thread where I use ZSNES. I typically rely on Geiger's Snes9x emulator. Since I use Linux, I run it through wine. Being on the road, my laptop would probably die if I did that, so I downloaded my old favorite emulator.

I like the gui too, but it's not the most accurate emulator. You can see in my picture that it doesn't handle overscan correctly. Regardless it works well enough, has a apt repo, and runs on a dorito, so I downloaded while on the road.

>> No.2557553

Thanks for the links I'll watch them tomorrow because I'll be going to bed in a while.
I also downloaded a PDF of >>2557470
and it was way too advanced for me but it does seem to explain a lot of interesting CS stuff, I'll maybe actually buy the physical version in a few years when I become good enough to understand it (it's like a thousand pages long and very complex).
I'm surprised there's no SNES emulator for Linux and you had to resort to using wine though, I assume you dislike windows?
Well, I'm leaving for today, thanks for the advice, cheers.

>> No.2557683

By my math this would have 20~characters that follow those rules.

3 ones from donkey kong
luigi and mario from super mario world
ioshy from ioshi island
luigi and mario from all stars mario 1
4 characters from mario 2 from all stars
2 from mario world 3 from all stars
kirby (dont know if kirby is different between different games)

>> No.2558519

I've watched the first one and took a look at some of the other videos and it was very interesting!
I did have to look up what two's complement was though since the explanation on the video was a bit confusing.
But I learnt it from here in just a few minutes.
The only thing I didn't like was that there was a lot of math I don't understand, that's something I need to work on.

>> No.2560771

Glad you enjoyed it. If I remember the course isn't math intensive, however part of the course is building a microprocessor and goes by very fast. Nice thing about video is that you can rewatch it as many times as you need to.

2's complement is as tricky as it gets binary wise. If you understand how to count in binary, how to add, how to do 2's complement, and how to AND, OR, and XOR, then you understand all you need to about computer integer arithmetic. Everything else can be built up from these functions (actually you really only need XOR or NAND, but it would be cumbersome). Feel free to ask questions if you can't figure something out. I'll be back from my trip in the morning and will have plenty of time to respond to any questions you (or anyone else) may haveabout computers.

>> No.2561254


>Glad you enjoyed it. If I remember the course isn't math intensive

That's the worst part about computers for me, I ignore the math parts because I'm bad at it and know I'll spend a lot of time thinking about it, it's an OCD kind of feeling so I ignore math cause I know it'll cause me distress.
I'm glad it isn't math intensive then.
You mentioned in a post you like math (and engineering), what do you like about it? Maybe it'll help me see it as more interesting instead of a source of mental distress.

>2's complement is as tricky as it gets binary wise. If you understand how to count in binary, how to add, how to do 2's complement, and how to AND, OR, and XOR, then you understand all you need to about computer integer arithmetic.

Awesome, I already know those things and know how to work with different number bases :)

>> No.2562878
File: 556 KB, 500x475, 1423099488391.gif [View same] [iqdb] [saucenao] [google] [report]

Just because you don't instantly get math doesn't mean you should give up on it. Nobody instantly gets it. That's literally like expecting a person to play an instrument perfectly the first time. It takes some thought and a little practice, but I think most people are capable of it. The key is to associate math with something interesting like a useful concept, and then you get excited about it. For example, I love computer graphics, and am now a pro at linear algebra, which is arguably the most useful math I know across all disciplines. It's astonishing how many things you can describe with a little math. Math and physics are beautiful, and we owe our modern way of living to engineering.


I've got a lot of free time now. This project has taken nearly 2 months instead of 2 weeks, but I've had to split my attention. I should be able to finish up the collision strategy I've developed and generalize mobs.

Also I'll do sound.

Let's talk sfx first. Send me a signed 16-bit PWM waveform a multiple of 16 samples long. Try not to make these samples extremely long. I have a codec from PWM to SNES Bit Rate Reduction (BRR) format.

For music, you supply the same kind of sounds. You get 8 voices, sound effects interrupting from voice 7 and to voice 0. Music is composed of a per voice stream of key and loop instructions:

>TTTT = 15-bit unsigned time until next instruction
>LLRR = Volume. Signed 8-bit values for both L and R stereo outs. Negative = reversed phase.
>PPPP = Pitch. 14-bit unsigned fixed point number with 2 integral and 12 fractional bits. Linear -2 to 2 octave.
>SS = The sound to play.
>AAAAAA = Attack-Sustain-Decay-Release (ASDR) envelope control. Complicated. We can talk.

> LLLL = 12-bit instruction offset
> NN = 8-bit number of loops before continue. 0 = Infinite loop.

Timing and echo commands too.

If this is too much, develop in a sequencer and we'll work on adapting it.

>> No.2563721


>Just because you don't instantly get math doesn't mean you should give up on it. Nobody instantly gets it. That's literally like expecting a person to play an instrument perfectly the first time

I'll keep that in mind and try not to let it stress me so much.
By the way, I learned what virtual memory is and a lot of stuff makes more sense now!
For example I didn't know how a compiler could decide at which memory addresses to place stuff at compile time, since it wouldn't know what memory would be free beforehand.
About the game, it's pretty awesome, only today did I notice there was a binary there (yes I'm that stupid haha), and I gave it a try, it's amazing what can be done with just assembly, congratulations dude.

>> No.2565435



What game it it from?

>> No.2565442

It's not from a game.

>> No.2566807
File: 64 KB, 510x480, level_editor.png [View same] [iqdb] [saucenao] [google] [report]

The game is really looking good. I tried out the level editor, pic related, and It was okay at first, but then instead of placing the selected tile, A btn would just clear out the tiles. Maybe I triggered some small bug cycling through or something? Okay, just tried again and was unable to recreate that issue.
Also, would you consider remapping the uppercut so its, jump -> punch instead of punch -> jump. It makes it look a lil cleaner imo since he doesn't jab first then uppercut. Hope this doesn't come off as demanding, it's awesome what you're doing, writing in assembly and showing us plebs how you're doing it.

>> No.2566851

Assembly was still the norm for programming 16-bit consoles; when the 5th gen started, then C++ became the standard.

>> No.2568047

The editor is implemented as a weird compromise between background and object resources, the two distinct graphical primitives available on the SNES. The cursor and a preview tile are implemented as objects and the level as a background. The 'glitch' you saw was probably you using a blank character (such that you could see the level tile underneath) and when you pressed A it placed the blank.

Since level data and background tile data are identical, I built the editor as a general tile editor, able to edit the H and V flip, priority, palette, and character of a tile fully. However only a small subset of characters (0x20-0x28 as seen in the top right corner) and only one palette (the default) are meant to be used.

Moreover objects and backgrounds have different resources. The mapping isn't one-to-one nor clean. To be specific, backgrounds only have 1 priority bit while objects have 2 (they are also interpreted slightly differently), and backgrounds have 1024 character choices while objects only 512. The backgrounds and objects don't share palettes either, so to draw the preview tile I had to load some background palettes into the object palette memory. Also I had to play around with where graphics are in VRAM to allow objects to use the background characters in addition to the sprite characters.

I need to put some limits on what the editor can place to make it easier to use.

Working on reprogramming collisions in a general way. Slow progress since I got back from my trip. It left me exhausted.

Oh yeah, I think I might just define a text file format to submit music in to make it easy to adapt and import people's work if they choose to contribute any BGM.

>> No.2568049

Writing this out I realized I could save myself a lot of effort and make things more general by dropping the preview tile object and just saving the current background tile when I go to overwrite it with a preview in case it needs to be restored if not written to.

>> No.2570421
File: 62 KB, 476x267, pep.jpg [View same] [iqdb] [saucenao] [google] [report]

>dwarf fortress
my man

>> No.2572335

Why does the emulator look like that or is it just a wallpaper and the emulator running in windowed mode?

>> No.2572391
File: 18 KB, 260x482, nds.png [View same] [iqdb] [saucenao] [google] [report]

Killer thread OP, this is the kind of OC that puts /vr/ a mark above the rest of the boards.

Mark my words, there's plenty of interested people lurking this. I've read every post so far.

Not as hardcore as what you're doing here in assembly, but I recently made a small platformer/katamari damacy style game (mashup) for the Nintendo DS in pure C.. it's also a very hardware restricted platform (4 Meg, can't get enough speed to do anything but trivial pong games unless you're using C or ASM, no dedicated floating point processor, etc.). Turned out to be 10,000 lines of C in the end. Similar setup to you (Linux + some windows tools in WINE), but with GCC cross compiling to ARM.

Keep it up!

>> No.2572416

Granted, compared to the SNES, the NDS is a bloody supercomputer

>> No.2574636

I've been playing around with the idea that jump -> punch = flying kick. That way you could stomp on someone, uppercut, or kick in the air and have a rock-paper-scissors thing going. Also I really like the slide motion from one button to the next, and I thought the current layout made that easy and fun to do. If you still disagree, let me know.

That's my laptop's desktop. I use the xmonad tiling manager as a UI. It's completely keyboard driven so it's very minimalistic. Like >>2570421 pointed out, the wallpaper is a Dwarf Fortress overworld map.

It's encouraging to know lurkers are around.

Your project sounds impressive and ambitious. When it comes down to it the only fancy thing I'm doing is coding in assembly, and that's not as hard as many make it out to be.


Sorry for the slow updates. Been looking for a place to move in the next 3 days. Should have something cool tonight or tomorrow to post.

>> No.2574670

'Nother lurker here.
Can confirm that assembly isnt that hard once you get to know the syntax and the hardware you'er writing it for.
For fun and for practice in the past i've gone and ported some of my C projects to assembly, and it wasn't too difficult.

>> No.2574834

It may not be impressive but it certainly does seem so.
From what little assembly I know it feels so limited, for example when programming in C I can use a graphics library, which someone had to make and even so it feels complex.
I can't imagine how complex it is to program graphics in assembly.
It's looking very cool so far.

>> No.2576884

I'm just curious, but what editor/IDE do you use to do your programming?

>> No.2577436

He seems like a pretty hardcore programmer, maybe vim or emacs? He wrote his own assembler.
I'm more curious about what he does for a living since he's so skilled.

>> No.2577494

If you see him in other threads he mentions that this is all practice for him. This is actually the most complicated project he's made evidently.

>> No.2577523
File: 499 B, 48x16, spritestuff.png [View same] [iqdb] [saucenao] [google] [report]

I do a lotta pixel art stuff in my free time and so I figured I'd whip up some new crates and tiles, since the current ones lack any shading, along with a little VRtan head in case you need it for a 1up or anything.
The palette is goofy and off because I have my copy of YY-CHR set to the Super Mario World palette by default, so you could replace it with the actual game palette if you do wanna use any of this stuff.

>> No.2578230
File: 93 KB, 1200x816, WDSI7.jpg [View same] [iqdb] [saucenao] [google] [report]

>>2576884, >>2577436 guessed right with vim. I don't like IDEs. I feel I am a better debugger when I am forced to reason about my code rather than rely on distracting IDE tools. I do use a debugging emulator however. I ply my coding skills at work, but I'm primary just a student of engineering and science.

Yup. I've learned a lot already like what a proper sprite animation library needs, how to do fast background and rectangular hitbox collision detection, how to do HDMA, and how to structure a sprite program using states. Really I just need to make a simple script program and sound driver and I would have most of the framework of an engine. This is practice for my next longterm project which will be something more like a full fledge game.

Cool. Upload your SNES 4-bit plane characters somewhere and I'll check them out.

So no new programming, but I've refined what the sound driver will be like:

> 8 Streams
> Each stream composed of instructions:
> CLOCK = Set timer period
> WAIT = Wait n timer ticks
> JUMP = Jump to instruction
> LOOP = Jump to instruction n times and then continue
> TEST = Jump to instruction if supplied address equal to true
> CALL = Push instruction counter and jump to subphase
> RETURN = Pull instruction counter
> SET = Sets one A-DSP register

Set can set any A-DSP register, although typically you might want to stick to 1 stream per 1 voice (there are 8 voices total).

> Per voice settings:
> vol = Volume (l and r)
> pitch = What pitch to play the sound at
> source = Which sound (source) to play
> envelope = Controls ASDR or manual envelope
> key on = Turns on voice
> key off = Turns off voice

> Per BGM settings:
> mvol = Main volume
> evol = Echo volume
> edl = Echo delay
> efb = Echo feedback
> c0-c7 = FIR 8 tap filter
> eon = Echo enable
> pmon = Pitch modulation enable
> non = Noise enable

I'm working on a cpu-apu protocol now (master-slave with no interrupt line, just ports) for bgm and sfx.

>> No.2578356

What program do you use to make sprites/pixel art?

>> No.2579767

YY-CHR and Microsoft Paint. The XP version. I use GraphicsGale sometimes too.

>> No.2579791
File: 27 KB, 158x132, 1438382362869.gif [View same] [iqdb] [saucenao] [google] [report]

Are there any tutorials you can link?
I want to make those game animations, they're called sprites if I'm not mistaken.
Like this, but for games, I would post something else but I don't have them on this computer.

>> No.2580291


>> No.2580864


>> No.2580960

OP's probably busy, there's no need to bump the thread, it's a slow board.

>> No.2581153

No, but surely Autosage will kick in soon, no?

>> No.2581178

I don't know what the bump limit on this board is, maybe it's better to make a new thread?

>> No.2581204

It could be. Maybe someone more versed with this board can shed some light, because 500 seems very near the cap.

>> No.2581217 [DELETED] 
File: 49 KB, 486x486, 1402470128397.jpg [View same] [iqdb] [saucenao] [google] [report]

Oh man what a good thread.

I can see so much progress. You guys did good.

When you make a new thread make sure you post a cool cap of the game.

>> No.2581221
File: 49 KB, 486x486, 1402470128397.jpg [View same] [iqdb] [saucenao] [google] [report]

Oh man what a good thread.

I can see so much progress. You guys did good.

When you make a new thread make sure you post a cool cap of the game in the OP.

>> No.2581224


>> No.2581271

I'll make the new thread, what do I put in the OP?

>> No.2581673

Fuck, there it goes. OP make a new thread quick!

>> No.2581681

Link to new thread: >>2581523

>> No.2581698

Thanks, I forgot to make a new one.

Name (leave empty)
Comment (leave empty)
Password [?]Password used for file deletion.