/vr/ - Retro Games

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

>>2447092
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.

Mechanics:
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?

Let's port Draw a Dinosaur

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

This project won't go further than ideas.

>>2447092

So

Who knows how to program in 65C816 ASM?

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

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?

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

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

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

>>2447154
Otherwise this faggot has a chance of being right.

>>2447317
>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.

>>2447092

>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?

>>2447172

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.

>>2447326
>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.

>>2447097
I would play this.

>>2447334

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.

>>2447334
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.

>>2447097
>>2447338
Find the loli and escape the Hansen?

>>2447092
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?

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

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

Have there actually been any SNES homebrews?

Because Genesis had a bunch. pic related

>>2447402
Yes, more than genesis.

>>2447092
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.

>>2447428
Like what?

>>2447326
>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?

>>2447441
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.

>>2447092
8 bit architecture is so much more pleasurable though

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

>>2447497
*game

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

>>2447504
http://wiki.superfamicom.org/snes/show/Backgrounds

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

>>2447495
SEP #$30

>>2447524
lda #$FF

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

The puzzle aspect could be diverting the water flow.

>>2447092
Fuck stupid ass puzzle games we need a fucking rpg

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

>>2447590
>underage b&

and it's dead already

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

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

>>2447650
dead as fuck

I'd be down for programming

>>2448071

Down for deez nuts?

>>2448134
got eeem

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
filedropper.???/jormungandr
filedropper.???/pong

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.

>>2448350

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

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

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

>>2447092

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!

>>2448681
wrote my own.

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

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

>>2448915
kek

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

>>2448834
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.

>>2448350
>>2449269
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?

>>2449279
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.

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

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

>>2449290
>>2449283
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).

>>2448350
so fucking cliche

>>2448915
>implying

>>2449269
>SMB
I meant Mario Bros (explicitly NOT SUPER mario bros)

>http://m.youtube.com/?#/watch?v=dSwSTGd3deU

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

>>2449339
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.

>>2449325
?

>>2449323
Thanks for bumbing the thread.

>>2449301
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.

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

>>2449645
NO
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.

>>2449775
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.

>>2449802
>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

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.

>>2449871
kek

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

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

>>2449930
Hmm. Interesting. It sounds like his MO

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?

>>2449938
MO?

>>2449952
Metodo operandi.

Things he does as a routine.

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

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

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.

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

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

>>2447092
Sorry, I'm an adult.

>>2450360
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.

>>2449279
>>2449281
>>2449290
>>2449518
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.

>>2449775
>>2449802
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.

>>2450340
>>2450257
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.

>>2450415

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.

>>2450415
Where you at in DC? Georgetown reporting in.

>>2450425
Not there yet, flying in.

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

>>2450360
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

>>2450415
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.

>>2450457
Spoken like a true adult :^)

Hope? Enthusiasm? Fun?

Bah -- That's kids' stuff.

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

>>2450510
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.

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

>>2450498
it kind of is

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

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?

>>2450523
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.

>>2450620
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.

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

>>2450654
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

>>2450495
Kinda like Nidhogg?

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.

>>2450742
No. Like this, but way more simple.
https://www.youtube.com/watch?v=SaidTw9bZxE

>>2451243
>>2451243
>>2451243
>After work today I'll sit down and lay the foundations of the program and code the reset routine to wipe the system clean.
http://wiki.superfamicom.org/snes/files/first-snes-program.7z
or you can use the routine inside the file "InitSnes.asm"

>>2451250
>>2450495
https://www.youtube.com/watch?v=Yx2wFwIrces

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

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

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

and instead of children, cheerleaders

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

>>24514894
^what this anon says

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.

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

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

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

>>2449269
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.

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

>>2451259
>https://www.youtube.com/watch?v=Yx2wFwIrces

BWAAH BWAWAWAHAWA WAA FWAA

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

>>2450257
I already own a game like that, anon.

OP like usual, is a massive faggot

>>2452418
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.

>>2451489
There's this thing called public domain.

>>2451489
>>2451541
>>2451271
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.

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

>>2452463
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..,.,.,.

>>2452448
Holy shit you really are a fucking faggot

Sanic the Hedgehog.

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

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.

https://github.com/gewballs/graviton

>>2452589

>>2452602
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.

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

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

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.

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

>>2453137
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.

>>2453152
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 ================================

>>2453152
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?

>>2452631
>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.

>>2453154
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)

>>2453157
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.


>>2453246
Neat

>>2453789
>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?

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

>>2453827
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.

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

YYYYYYYYXXXXXXXX
VHPPCCCNNNNNNNN

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.

+----------->X
|
|
|
v
Y

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.

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.

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

>>2454098
Who?

>>2454108
The most radical /vr/ mascot, of course!

>>2447092
>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.

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

>>2454181
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.

>>2454184
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

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

-BBBBBGGGGGRRRRR

5 bits of RGB, with an unused 16 bit.

>>2454195
5 bits for a color? Is that in decimal?

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

>>2454204
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:

-BBBBBGGGGGRRRRR

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.

>>2454218
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

>>2454218
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

>>2454235
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.

>>2454235
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)

http://www.mediafire.com/download/5w3f3w9gs7syo6o/vrgrid.rar

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

>>2454480
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

>>2454480
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.

>>2454615
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?

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

http://pastebin.com/DarmP8ah

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

>>2454628
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.

>>2454480
pcx2snes

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.

>>2454480
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.

>>2455224
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?

>>2455241
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.

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

>>2455584
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.

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.

>>2455662
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?

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

>>2455673
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?

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

>>2455241
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?

>>2455703
>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

>>2453735
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!

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.

>>2452461
Just use bsd

>>2456757
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.

>>2456757
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)

>>2456757
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?

https://soundcloud.com/battledancer/07-spell

>>2457361
DAY 5 =========================================

>https://soundcloud.com/battledancer/07-spell
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.

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

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

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

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/

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

>Implying /vr/ isn't

>>2459265
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.

>>2459265
>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.

>>2459648
>katawa shojo
That wasn't /v/.

>>2459713
>/a/

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.

B U M P

U

M

P

>>2452449
>>2452461
>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:

DO WHAT THE FUCK YOU WANT TO PUBLIC LICENSE
Version 2, December 2004

Copyright (C) 2004 Sam Hocevar <sam@hocevar.net>

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.

DO WHAT THE FUCK YOU WANT TO PUBLIC LICENSE
TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION

0. You just DO WHAT THE FUCK YOU WANT TO.

>>2460318
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.

>>2460321
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?

>>2460354
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.

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

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

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

>>2460452

>>2460580
Exactly.

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

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?

>>2447092

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

>>2460318
>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.

>>2450637
>broad sword
My dick is broader than that.

>claymore
Looks more like a gladius.

Seriously, what the fuck is up with that magazine?

>>2461879
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.

>>2461828
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.

>>2462270
>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

>>2462460
>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

>>2462520
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.

>>2462547
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.

>>2462460
>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.

>>2462460
>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.

>>2462547
>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.

>>2454480
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.

btw
DAY 7 ===================================

>>2463804
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)

>>2463804
>>2463808
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

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

>>2447339
There has been indy SNES games made.

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

>>2463924
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.

>>2463914
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.

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

>>2464283
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.

>>2463962
I think we can make the deaths nasty.

>>2464324
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.

>>2465675
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.

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

>>2465675
>>2465683
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?

>>2465851
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.

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

>>2466013
Can you put the Spy Hunter tune in it?

>>2466013
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

>>2466479
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.

>>2467401
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:

VHPPCCCNNNNNNNNYYYYYYYYXXXXXXXX

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 {
$09
$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...

>>2467424

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:

XXXXXXX YYYYYYY VHPPCCCNNNNNNNNN ------SX

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 {
$0004
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?

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

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

>>2467825

2spooky

>>2463535
>>2463542
>>2463552
>>2462578

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?

>>2463552
>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:

http://lparchive.org/Policenauts/Update%2041/

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

>>2468985
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)

>>2463552
>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

https://tcrf.net/Mega_Man_X6

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

>>2469059
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

>>2469085
NAND best gate, all others need not apply.

>>2469079
>tcrf.net

toppest fucking lmao

>>2469132
NOR is a universal gate too, bra

bump a bit

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

>this thread
>dying

not on my watch. where the fuck are you op

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

>>2471529
Super Smash Brother's SNES

>>2471619
We need 5 other really good programmers to accomplish this

>>2469213
wat

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.

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

>>2471449
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.

>>2472480
Damn weed slows me down a bit.

>>2471634
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.

/offtopic

Any updates OP?

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

>>2473369
>>2473364
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.

>>2473439
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.

>>2473439
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.

>>2473439
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

>>2474409
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.

>>2449372
>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?

>>2474409
>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

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

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

>>2474568
>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.

>>2474461
that doesn't even make sense

>>2474574
Chill out fag

>>2474574
Okay, haha, you got me.

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

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.

>>2474409
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

>>2475034
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.

Bump

>>2475006
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.

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

>>2477968
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.

>>2478069
what about sounds, anyone taking care of those?

>>2478104
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.

Sorry.

>>2478069
>A title screen would be cool too

A title would be cool lol

>>2478417
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.

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

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

>>2478069
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
VHPCCCNNNNNNNNNN

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.

>>2478629
I have no idea.

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.

>>2479542
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).

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

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

>>2447092
OP here. Bump. Will have updates this evening.

>>2483897
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?

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.

>>2484092
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.

bumping, and while i'm at it

>>2472172
>>2469132
>>2469085
>>2469079
>>2469021
>>2468985
>>2478629
>>2452543

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

also

>>2449946

>>2484743
>source?

http://www.pixiv.net/member_illust.php?mode=medium&illust_id=391970

Not animated though?

>>2484458
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.

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

>>2485367
New! Jumping! And to the left!

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

>>2472172
>>2484743

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

http://tvtropes.org/pmwiki/pmwiki.php/UsefulNotes/VideoRAM

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

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

Such wizardry m8

>>2485443
http://tvtropes.org/pmwiki/pmwiki.php/Main/HowVideoGameSpecsWork

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

>>2484743
Let's go through the list...

>>2472172
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.

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

>>2486071
...cont...
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.

>>2486120

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.

>>2486085

bank switching?

>>2486151
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.

>>2486164
Go to bed, Ken M.

>>2486135
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.

>>2486085
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:
$0000
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
0xDEADBEEEEEEEEF => CPU $0100-$01FF <=> RAM $DEADBEEEEEEEEF00-$DEADBEEEEEEEEFFF

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.

>>2484743
>>2469079

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.

>>2486818
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.

>>2469079
>>2486847
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.

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

>>2486886
> 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.

>>2486905
>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?

>>2486898
Did you even read the thread?

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.

>>2487484
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.

Bump

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

>>2489517
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.

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

>>2489742
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.

>>2489772
Yes and no.

>>2489742
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

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
meh

>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

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.

>>2491468
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.

>>2491546
Nope, just a faggot who can read a manual.

>>2492071
D-Pad=duh
Double tap D-Pad left or right = Run
Y=Attack
B=Jump
Attack, then Jump = Uppercut
Start=pause
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)

>>2492071
>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?

>>2492606
The latter. Torus 4 eva.

bump

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
respawn
hurtboxes
entity intersection (ie boxes that move)
crushing death
gravity
player 2
(Also I want a kick attack too...)

>>2494805
Why would it only work on blue?

bump

>>2495035
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:

BGRCCCCC

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.

>>2496098
cool

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.

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!

>>2497109
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.

bump

>>2497106
Looking good, OP.

>>2447124
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

>>2499143
>why

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

>>2499143
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.

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.

>>2499143
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.

>>2499179
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.

>>2499429
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.

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

>>2499504
>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!

>>2499568
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.

>>2499579
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.

>>2499584
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).

>>2499603
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

>>2499504
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.

>>2499612
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.

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

>>2499663
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*)

>>2499634
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.

>>2499680
>Do a spin jump
>"Fuckfuckfuckfuckfuckfuck"
Man, this is great

Awesome project.

Bamf!

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

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

B U M P

U

M

P

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...

>>2505457
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
http://www.amazon.com/Programming-65816-Including-65C02-65802/dp/0893037893

(2) SNES Development Manual
http://www.romhacking.net/documents/226/

(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).

>>2505498
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?

>>2505512
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.

>>2505527
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.

>>2505546
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.

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:

github.com/gewballs/graviton

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.

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

>>2506016
>>2506016
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.

>>2506016
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.