[ 3 / biz / cgl / ck / diy / fa / ic / jp / lit / sci / vr / vt ] [ index / top / reports ] [ become a patron ] [ status ]

/vr/ - Retro Games


View post   

File: 30 KB, 512x448, bahamut_lagoon_hbg.png [View same] [iqdb] [saucenao] [google]
7906287 No.7906287 [Reply] [Original]

Gameplay and development discussion:
What homebrew / hacks are you playing /vr/ ?

Are you working on anything? Would you like to learn? Projects and questions welcome.

Communities:
romhacking.net
smwcentral.net
metroidconstruction.com
sonichacking.org
pouet.net

IPS Patcher:
romhacking.net/utilities/240

Archives:
archive.org/details/rom-hack-patch-archive
mediafire.com/folder/50m95vbbuyf25/vr's_ROM_>Hack_Recommendations
mega.nz/folder/jpMxlQyZ#oCwbRyPFaMcZl3gOF5mvSg
mega.nz/folder/TBgnhIxS#aKF0Cv0DA9kYI_qUI_gXvg

NESdev:
wiki.nesdev.com
forums.nesdev.com

SNESdev:
wiki.superfamicom.org
github.com/alekmaul/pvsneslib

N64dev:
n64dev.org

Sega Dev:
smspower.org

Mega Dev:
gendev.spritesmind.net/page-doc.html
github.com/Stephane-D/SGDK

Saturn Dev:
antime.kapsi.fi/sega/docs.html
segaxtreme.net
www.jo-engine.org

GB Dev:
gbdev.gg8.se/wiki

GBA Dev:
forum.gbadev.org
github.com/pret

DS Dev:
ndshb.com
forums.serenesforest.net/index.php?/topic/26913-nintenlords-hacking-utilities

Amiga Dev:
eab.abime.net

Zed Dev:
worldofspectrum.org

Previous: @ desuarchive.org/vr/thread/
>>7865385
>>7835658
>>7787576
>>7772819
>>7727686
>>7679650
>>7631727
>>7597758
>>7544203
>>7485931
>>7433626
>>7373559
>>7311797
>>7262583
>>7205614
>>7155960

Want something here? Post it for the next thread.

>> No.7906293
File: 556 KB, 792x524, akira_64.png [View same] [iqdb] [saucenao] [google]
7906293

what's your dream homebrew, /vr/?

>>7787584

>> No.7906305

>>7906287
F

>> No.7906308
File: 396 KB, 1060x930, goldeneye_SM64.png [View same] [iqdb] [saucenao] [google]
7906308

>>7906287
Previous thread: my bad
>>7865482
>>7865482
>>7865482

>> No.7906317

>>7906287
Does someone knows how to build the bahamut lagoon translation source code?

>> No.7906919
File: 1.10 MB, 800x1141, LarryNES.jpg [View same] [iqdb] [saucenao] [google]
7906919

>>7906287
Does anyone have the rom for this game?

>> No.7907854

Hyper Metroid graphics seem to have been made in mind for a LCD monitor with a gamma of 2.2
It is very dark on a real CRT and you have to increase brightness.

>> No.7907865

do they sell physical copies of ROM hacks in stores in places like Hong Kong?

>> No.7907901

>>7906293
What would the gameplay be like?

>> No.7907938

>>7907865
My first contact with internet-made hacks was when I got a chinese cart with Spider-Man 2, so, I guess a few?
Not sure if they still make those nowadays, though.

>> No.7908376

F

>> No.7908532

Someone use Xeno GC here ?

>> No.7908579

is there an ff6 romhack that is the jp version translated?

>> No.7908845
File: 216 KB, 587x515, 1624925680079.png [View same] [iqdb] [saucenao] [google]
7908845

Bothered to remove the logos from the Dejap/Tomato version of Bahamut Lagoon.
https://files.catbox.moe/1gtlwf.zip
This is not related to what happened, btw

>> No.7908920 [DELETED] 

>>7908845
i hope he faked his death, i for 1 never hated byuu

>> No.7908923

Is there still a list of recent dumped and undumped games?

>> No.7910121 [DELETED] 

https://www.youtube.com/watch?v=mSFHKAvTGNk

>> No.7910506

Why haven't you started a disassembly of your favorite game, anon?

>> No.7910586
File: 60 KB, 320x240, 320px-SSF2XMatchingService_title.png [View same] [iqdb] [saucenao] [google]
7910586

I've been wanting to do this hack for a while

Game: Super Street Fighter II X For Matching Service
Platform: Dreamcast
Language: Japanese

Goals
-English translation of all menus, names, and win quotes
>removal of matching service and online features from main menu
-Replacement of voice samples to match USA release aka Super Turbo. Example: change Dee Jay's "Slash!" to "Max Out!"
>customize stage and character palettes to match the Super Street Fighter II palette
>replace audio with arranged soundtrack from one of the other releases of the game
>add 240p mode option which should be attainable using code borrowed from the Dreamcast Third Strike release which has this mode.

What do you think of this idea?

>> No.7910590

>>7910586
Well I messed up my formatting...

>> No.7910883

>>7906317
post the code, stuff like this usually comes with a makefile

>> No.7910946 [DELETED] 

>>7908920
>Trusting an anon claiming to be "Byuu's friend".
>The Dox thread from that forum doesn't even reveal his name.

Need to see an actual body to confirm it.

>> No.7911058 [DELETED] 

>>7910946
>Need to see an actual body to confirm it.
Sneaky way to get fetish pics.

>> No.7911335
File: 110 KB, 940x940, laughing (2).jpg [View same] [iqdb] [saucenao] [google]
7911335

>>7908923
No. There was no point doing that once some kid on the internet announced that the full set he downloaded from emuparadise had everything.

>> No.7911412

>>7908923
I think around half of this list was dumped.
https://www.reddit.com/r/Roms/comments/c23i85/nes_homebrew_games/
The only thing I'm aware of that was dumped from this site was ドラキュラの城 - Dracula's Castle.
https://www.gameimpact.info
Then there's these:
まほう少女せれな - https://anayasoft.booth.pm/items/1146980
懐式倣緋萃 (demo) - https://jiyugiga.booth.pm/items/662593
西武ロードリスト蘭のチップチューン地獄 - https://www.dlsite.com/home/work/=/product_id/RJ238358.html
ファミ姦 - https://www.dlsite.com/maniax/work/=/product_id/RJ017215.html
東方野球拳FC - https://www.dlsite.com/maniax/work/=/product_id/RJ084786.html

>> No.7911480 [DELETED] 
File: 773 KB, 900x962, 1624973746550.png [View same] [iqdb] [saucenao] [google]
7911480

>>7911058
Why is it when faggots are "losing arguments" they always accuse their opponents of fetishizing something? Defense mechanism?

>> No.7911485 [DELETED] 
File: 773 KB, 900x962, 1624973746550.png [View same] [iqdb] [saucenao] [google]
7911485

7911058
Why is it when faggots are "losing arguments" they always accuse their opponents of fetishizing something? Defense mechanism?

>> No.7911490

>>7911335
>>7911412
I see

>> No.7913013

https://www.youtube.com/watch?v=qS_LgZv_ryg

>> No.7913240

>>7913013
There's lots of stuff in this hack that I wish were stand-alone patches, or available in those SMB editors. Mainly the Hammer suit.

>> No.7914364
File: 52 KB, 634x475, polystation.jpg [View same] [iqdb] [saucenao] [google]
7914364

https://www.retroreversing.com/official-playStation-devkit

>> No.7914776

>>7913240
What would be a good system for organizing stand-alone patches? It would have to be a bit “smart” wouldn’t it? Or rely on an assembler to automatically organize code and labels.

>> No.7914998

>>7914776
Uh
I don't get what you mean, I just usually download patches from romhacking.

>> No.7915230
File: 246 KB, 1920x1079, smb_disasm.png [View same] [iqdb] [saucenao] [google]
7915230

>>7914998
> stand-alone patch
he means patches that can be combined together. unfortunately there is no such thing: if two patches change the same part of the game to achieve two different results it's game over. there's no "automated patch collision tester" as far as i know, you'd have to conduct that work by hand, or you know, just try it and see if the game breaks.
> It would have to be a bit “smart” wouldn’t it?
yeah. that would be an interesting and fairly difficult problem to solve. IPS' are generally unaware of the format of a game: they just change the right bytes compared to an exact copy of the original. patches that would work together change small parts of the game without rearranging the larger structure of it.
> Or rely on an assembler to automatically organize code and labels.
I suppose something like this could be built, but, it's hard for a disassembler to know what is code and what isn't. instructions and data look the same as far as it knows. emulator debuggers solve this by acutally running the code and making educated guesses about what's what.
SMB is a special case though, because a full disassembly exists, unlike most games. if two patches used this to change the overarching structure of the game, combining two IPS patches just wouldn't work. it might be possible to build some disassembler / DIF analyzer that pieces together similar parts of the game and finds what you're trying to change from each patch, but, that would be a project and a half. good luck.
TL;DR it might be possible kinda in some situations but it would be very difficult to organize / build something that does this automatically.

>> No.7915304

>>7915230
I meant like how some SMB graphic improvement patches are compatible with the 2 player co-op patch for instance, yes. Or how some Mega Man patches, like selecting weapons with Select, or the Slide and Charged Shot patch for MM2 can be used with others.

>> No.7915346

>>7915304
Right, it means they didn't touch the overarching structure of the game and changed two unrelated parts. It's not something you can guarantee though: Patch A might work with Patch B or Patch C, but patch B and C may be incompatible. Patch D might work with Patch B or Patch C but Patch A and D might be incompatible.
All i'm trying to say is you can't guarantee something is a "stand alone patch" because they all change something.

>> No.7915372

>>7915346
Oh yeah I know, but it's better than nothing. You could see what's compatible, or even start patching those, and then reworking the graphics manually from there.

>> No.7915375

>>7915346
>>7915372
As opposed to going with the whole Tower RE package.

>> No.7915420

>>7906293
Corpse Party 64

>> No.7915448

>>7915372
Right, you'd have to do it by hand on a patch by patch basis and essentially build a compatibility matrix. Which brings us back to:
> What would be a good system for organizing stand-alone patches?
Unfortunately there isn't =(
It would be a very difficult problem to solve with any sort of universality.

>> No.7915514

>>7915448
Hm, maybe a symbol of incompatibility on less sociable patches?

>> No.7915525

>>7906287
Are translations allowed here or are they a separate thing?

>> No.7915681

>>7915525
Why not?

>> No.7915809
File: 57 KB, 640x349, always_has_been.jpg [View same] [iqdb] [saucenao] [google]
7915809

>>7915525
Translations are romhacks: It's not just converting text. The code has to be altered to accommodate new / different text and graphics.

>> No.7916120

>>7915230
I think it could be done if the patches follow a predictable structure. Patch 1, overwrite 10 byes, 2 bytes being a label resolved at linker stage, reference data or code in a clean expanded memory bank.

If an assembler had the functionality of overwriting an existing rom it would be easy. Like in a ca65 linker script, instead of setting FILL to a byte value, being able to set it to a ROM file.

>> No.7916194

>>7906287
Here's how to build the byuu's bahamut lagoon translation source code
https://pastebin.com/ENAk4akc

>> No.7916535
File: 64 KB, 300x276, mario_isScrewed.png [View same] [iqdb] [saucenao] [google]
7916535

>>7916120
As long as the main structure isn't touched it could be done. Most romhacks just change a few things here and there, or add subroutines pointing to unused spaces in the ROM. That is all well and good and perhaps adaptable with automation.
Where you run into trouble is if the game was reassembled and data / branches / jumps were shifted or moved around. You (maybe) could regenerate two linking structures with each file and somehow match them up. You'd run into Real Trouble if you ran out of space or you had to combine the patches in such a way that branches no longer fell within the -128 / 127 byte range.
For most cases i think your plan would work: I don't know if anyone has tried to make a disassembler / linker. Sounds like a fun project.

>> No.7916639

>>7906293
Darkstalkers (SNES)

>> No.7916672

>>7916120
This exists for SMW, in a few different ways. There's GPS for adding new blocks. PIXI (or spritetool or something) for adding new sprites. UberASM for adding level/mode dependent code.

You do have to write your asm in specific ways, and some of the publicly available code can--and does--stomp on each other's toes, but it works surprisingly well.

There's no reason, aside from maybe rom/ram space constraints, that SMB1 couldn't have similar tooling. You'd just need to build it.

>> No.7916681 [DELETED] 
File: 252 KB, 1024x768, 20181222-145350_1024x1024.jpg [View same] [iqdb] [saucenao] [google]
7916681

>>7910586
I took the first step which is checking to see if the game has ADX audio. ADX is the format which enables easy hacking of Dreamcast music tracks. The ADX logo is visible on the back of the GD-ROM case.

>> No.7916725

>>7906293
Darkstalkers all the niggas edition, like the PS2 version has, but on CPS2

>> No.7916781

>>7916672
If you have a disassembly and the romhacks are code snippets instead of byte replacement, it is way easier to combine hacks and many more things are on the table. This isn't the case for the majority of games though unfortunately. >>7910506

>> No.7916787

>>7916725
Nah, better on SNES system.

>> No.7916792
File: 5 KB, 385x145, smb_clouds_bushes.png [View same] [iqdb] [saucenao] [google]
7916792

>>7916672
>SMB1 (could) have similar tooling. You'd just need to build it.
There are full level editors with ROM expanders like SMButil. SMB has been converted to different mappers for hacks before. Armed with the disassembly many things are possible. It just doesn't have the community / interest that SMW has.

>> No.7916960

>>7916787
make it Famiclone

>> No.7916964

While we're at it, I heard the SMB2 randomizer inserts new power-ups into the game. I couldn't run it, but new power-ups always sound like great for new patches.

>> No.7917325 [DELETED] 

>>7916787
>XD
Trolling is so fucking gay.

>> No.7917327

>>7906293
Widescreen SNES Zombies Ate My Neighbors to remove the one thing the Genesis version has going for it, and that's the map not getting in the goddamn way so much.

>> No.7917330

>>7916787
This is so fucking dumb, shut up. Even the officially made, less demanding, chip using SFA2 sucked peckers. I'm asking for a romhack that would actually be the best version of the game, you stupid cocksucker.

>> No.7917335

>>7906287
Famicom Megami Tensei II translation when? That SFC version is balls. The wrong child died.

>> No.7917485
File: 218 KB, 280x342, zombies_ate_my_neighbors.png [View same] [iqdb] [saucenao] [google]
7917485

>>7917327
Genesis has a different map placement or no map?

>> No.7918969
File: 318 KB, 1820x1188, 1428828701.jpg [View same] [iqdb] [saucenao] [google]
7918969

Has anyone made a homebrew game for the Sega CD 32X?

>> No.7918994

>>7918969
i don't think so but this would be hilarious if it actually ran on console
https://www.youtube.com/watch?v=TrEPgrU_8zA

>> No.7919062
File: 7 KB, 229x220, the fucking goat.jpg [View same] [iqdb] [saucenao] [google]
7919062

>>7906287
Am I the only one who still visits the elder god? It's the only place I found such relics as an MSX emulator for N64 which I still use till this day.

>> No.7919086

>>7917330
Actual it can work than SFA2 port since it held less data

>> No.7919135

>>7919062
I didn't know they still update it.

>> No.7919219

>>7917330
>Romhack
>Whining
Don’t ask.

>> No.7919227
File: 321 KB, 1719x929, SPC_generation.png [View same] [iqdb] [saucenao] [google]
7919227

>>7919062
all the time. the music selection is incredible. i have winamp plugins to generate OST's with emulated soundchips at ridiculous bitrates. they take up no room on the harddrive and sound better than compressed music ever could.

>> No.7919260

>>7910883
Here's the source code, sorry for taking so long
https://near.sh/downloads/bahamut-lagoon-en_v12.tar.xz

>> No.7919548

>>7919227
music section is fire

>> No.7919578

>>7919227
>Zophar
>for extracted music
You can do better. Far better. Using Zophar as a source for that is like using ZSNES for emulation.

>> No.7919593
File: 25 KB, 500x374, olivia_munn_g4.jpg [View same] [iqdb] [saucenao] [google]
7919593

>>7919578
uh no dude. you are completely wrong. are you retarded?
it's 0's and 1's extracted from each game. i am using the actual source files with winamp to generate it the same way an SNES or an emulator would.

>> No.7919598

>>7919593
Oh dear. Oh honey. You poor, sad individual.
Here. I'll just drop this for you and you can know what real rips look like.
https://hcs64.com/mboard/forum.php?showthread=26929

>> No.7919610
File: 102 KB, 228x271, goldeneye_face.png [View same] [iqdb] [saucenao] [google]
7919610

>>7919598
i don't think you understand how digital things work.... are you going to make me start DIFfing SPC files to prove they are 100% identical you incompetent shitbrain?

>> No.7919614

>>7919610
not him but rips CAN be incorrectly ripped, just like roms can be incorrectly dumped. stop trying to act superior because you are fundamentally wrong.

>> No.7919660
File: 223 KB, 1824x1004, SPC_youre_both_retarded.png [View same] [iqdb] [saucenao] [google]
7919660

>>7919598
>>7919614
You're both retarded. I downloaded MMX1 from the other website and compared the Intro Stage rip to the rip from Zophar. Besides the header and footer metadata that was added, which means that two different people ripped them, they are COMPLETELY 100% IDENTICAL.
so uh yeah. nice try. should i compare more of them? i don't really want to and i have other shit to do, so uh, yeah. are you happy now?

>> No.7919685

>>7919660
holy goddamn, you are retarded. I said it's possible, not that it was. zophar was a source of some bad rips back in the day, be it data errors or as your screenshot showcases so well: mistagged. so I will never trust it today even if they fixed their shit up, nevermind the fact that they've always had a wildly incomplete archive

>> No.7919725
File: 137 KB, 575x800, brian_eno.jpg [View same] [iqdb] [saucenao] [google]
7919725

>>7919685
>mistagged
hmmmm i didn't even think about that. come to think of it, some of the metadata from the Zophar rips is a bit fucky. i was just thinking about the samples and the songs themselves, but, you bring up a valid point.
i do like the search and grouping functionality at Zophar though, like, if i find an OST i like i'll click on the developer or publisher and rifle through those. the previews are nice as well; i can listen for a few seconds and decide if the OST is worth downloading. it's harder and harder to find new good stuff once you have tens of thousands of files and most of the major companies checked off the list.

>> No.7919731

>>7919725
I will admit that those are indeed good features to have over joshw.info's barebones file system.

>> No.7919745

>>7919731
i guess i was a little too defensive of Zophar's rips considering i already have tens of thousands of them.
SNES is less of a concern because the APU handles so much of it, but, with systems like the NES / genesis where the main processor and it's code are controlling the audio chip bad / inaccurate rips are more likely to occur.

>> No.7919891

>>7917330
>I'm asking for a romhack that would actually be the best version of the game
Which would be SNES.

>> No.7919914

>>7919846
>>7918403
It can be done, probably 128k ROM is good enough since there's really only three distinct levels/tile sets. The levels would have to be shortened/broken down into manageable pieces to fit in the NES's memory space. You couldn't do it at the same framerate as the PC especially as there's diagonal scrolling.

>> No.7919923

>>7919914
https://nesmaps.com/maps/Castlevania/CastlevaniaCompleteMapB.html

You'd be surprised how short the levels are here since when playing (or when you were a kid) they seem immense and endless. It's not as if you have a huge amount of room in 40k memory space.

>> No.7920071

>>7919745
>but, with systems like the NES / genesis where the main processor and it's code are controlling the audio chip
The Mega Drive has a separate Z80 to drive the audio chip. Though you could use the main CPU to drive it if you want to.

>> No.7920118 [DELETED] 
File: 111 KB, 850x626, MV5BYjU1ZDAzNDctMzViOS00ZjM1LTk1N2YtYTY2MGI2MGZjZGNhXkEyXkFqcGdeQXVyMTEwNDU1MzEy._V1_.jpg [View same] [iqdb] [saucenao] [google]
7920118

I beat Hyper Metroid.
I loaded one save state during the escape because I died and I didn't want to fight mother brain and escape Tourian again.
Maybe I'll go back and do the whole escape from scratch again to say I beat the whole thing without a single save state but I'm too enthusiastic to do that.
Clear time was 07:36 with 73% items collected.

It was a good game but is too long and too open. I think Redesign is better.

>> No.7920124

>>7920118
>I loaded one save state during the escape
So you didn't beat it.

>> No.7920125
File: 111 KB, 850x626, MV5BYjU1ZDAzNDctMzViOS00ZjM1LTk1N2YtYTY2MGI2MGZjZGNhXkEyXkFqcGdeQXVyMTEwNDU1MzEy._V1_.jpg [View same] [iqdb] [saucenao] [google]
7920125

I beat Hyper Metroid.
I loaded one save state during the escape because I died and I didn't want to fight mother brain and escape Tourian again.
Maybe I'll go back and do the whole escape from scratch again to say I beat the whole thing without a single save state but I'm not enthusiastic to do that.
Clear time was 07:36 with 73% items collected.

It was a good game but is too long and too open. I think Redesign is better.

>> No.7920128

>>7920124
I knew you would say that.

>> No.7920131

>>7920128
And yet you still tried to get away with it. Admirable, but foolish.

>> No.7920138

>>7920125
>I liked redesign better
Why exactly? I think them crippling wall jumping was too much, felt like an autist that was rump-ravaged at the sandbox-y nature of Samus' controls and physics and wanted to make sure it was only autist-approved fun.
The heavier jumps were satisfying, I won't deny that.

>> No.7920139

>>7920131
which anime are you from

>> No.7920143
File: 50 KB, 1068x640, praise yuria.png [View same] [iqdb] [saucenao] [google]
7920143

>>7920139

>> No.7920146

>>7920138
It took me about 20 minutes to get out of the first pit after you get the wall jump boots, but after that I had no issue wall jumping anywhere else in the hack. The timing is more delayed from original Super Metroid but once you've got it you've got it.
I enjoyed the different physics because it reminded me that Redesign is a new game. Hyper Metroid has different physics too.

I beat Redesign not long after it came out on a modded Xbox and used some save states, particularly in the escape sequence of that game too. And the grappling hook room in Norfair. But a few years later I went back and beat it on a flash cart with any save states at all.
Then I sold my flash cart to buy a new computer.

>> No.7920147

>>7920146
I was more pissed that walljumping is only allowed on certain services and you MUST have two walls in order to climb.

>> No.7920148

>>7920139
Boku no pico

>> No.7920186

>>7920131
Well you got me to replay it and I just completed the escape in a single segment from the start. I didn't re-beat Mother Brain but that battle is very easy so I didn't bother.
In the rest of the game pre-escape I didn't use any save states at all. I set a few but ended up not using them.

>> No.7920189

>>7920186
I was just Joshing you man but good job anyway.

>> No.7920190

>>7920189
I do feel better about it and tomorrow I'll probably go back and do a single segment from the last Tourian save beating Mother Brain again to say that I beat it just like a real cart (other than the practice I had from the earlier runs).

>> No.7921324

https://www.youtube.com/watch?v=S8cEtFikQik

>> No.7921365

>>7908845
Thanks for this... After what allegedly happened with Near, I wanted to give this game a shot, but his translated version doesn't run on older emulators that my handheld uses, and those logos were obnoxious and ugly on the dejap version.

>> No.7921380
File: 25 KB, 648x409, genesis-zombies-ate-my-neighbors-screen.png [View same] [iqdb] [saucenao] [google]
7921380

>>7917485
it's got a big bar on the side

>> No.7921385

>>7919923
>It's not as if you have a huge amount of room in 40k memory space
Castlevania is 128k ROM though?

>> No.7921508
File: 65 KB, 721x634, zombies_ate_my_radar.png [View same] [iqdb] [saucenao] [google]
7921508

>>7921380
it's kind of nice to not have it in the gameplay. i assume they were just showing off the SNES layering / transparency abilities but the placement is very unfortunate.
say i were to move it, what would be a good solution? it might be possible to toggle / disable the other HUD elements and stick it more to the top out of the way.
i don't think the Genesis solution is very good either: a real CRT would probably cut alot of that off as it's not in the NTSC safe area at all. genereally you need things within 16x16 pixels away from the edges to be visible. ...maybe the Genesis doesn't have to worry about that though? i'm not all that familiar with using it on a Legit setup, though i do have one and very recently a flashcart.

>> No.7921518

>>7921385
you'd be surprised how much you can fit in 32K of code with properly written assembly language. that game could probably be done.

>> No.7921551

>>7921385
Yes but the NES can only see 40k of ROM at a time. Imagine NES ROMs as being a collection of 40k sized programs you link together and select which one is currently active. As a consequence game levels are naturally going to be pretty short compared to what they are on 16-bit consoles.

>> No.7921580

>>7921551
> Yes but the NES can only see 40k of ROM
32k of ROM. the other 8k is CHR. you can't mix and match.

>> No.7921604

it's kind of like on the Atari 2600 where the ROM space is 4k and if you had a 16k game like Dig Dug or Solaris, the game is basically four 4k programs that you switch between.

>> No.7921630

>>7921604
>the game is basically four 4k programs that you switch between.
welllllllll yes and no. bank switching is instantons. lots of times there was a main part of the program that stayed in memory / was repeated in each bank and the banks contained data for different levels / music / animations / what have you.

>> No.7921648

>>7919891
Shut up, you fucking retard.
>>7919086
Fucking huh? Even the first Darkstalkers game is larger than SFA2 and is way more ambitious regarding sprite size, frames in memory, speed, and sprites on screen. Fuck off tards.

>> No.7921672
File: 91 KB, 720x540, computerdoge.jpg [View same] [iqdb] [saucenao] [google]
7921672

>>7921630
>instantons
instantaneous LUL

>> No.7921743

>>7921508
i honestly never minded the map placement. it's not too in the way and it's transparent. i also didn't keep it open, just a quick toggle usually to see if anyone's near.

>> No.7921795

>>7921630
Banking on the 2600 wasn't that sophisticated, it was literally just switching between each 4k block of the ROM.

>> No.7921820

>>7921795
yeah true. on the NES normally you would switch banks in 16k pieces and some more advanced mappers let you switch in 8k pieces. but usually you have one fixed bank that contains core game routines as well as the banking code. there are other exception, LOZ for example copies some core routines to the PRG RAM so they can be accessed no matter what bank is active.

>> No.7922041

I feel bad using savestates on regular games, but not on romhacks, why is that?

>> No.7922185

>>7921551
16-bit consoles work in a somewhat similar way but there's no banks and thus no limit on how much code/graphics/sound can be used except the total ROM size.

>> No.7922190

>>7919914
60 fps is generally only achievable on the NES if you're scrolling in one axis in the direction of the mirroring. Thus SMB has no issue with 60 fps because it's set to vertical mirroring and only ever scrolls horizontally. SMB3 has 8 directional scrolling so it can't run at 60 fps, a lower framerate is necessary.

>> No.7922197

>>7922041
ROMhacks are often made by amateurs that have a poor grasp on balance.

>> No.7922201

>>7922041
some romhacks are much more difficult and redesigned levels aren't made by professionals: i've been through a softlock or three in my time. with a published game you know it's beatable and not broken in all but the worst cases.
it's amazing though being able to relive games like Super Metroid and Mario 3 like it's the first time through again.

>> No.7922203

>>7922190
sometimes a lower framerate was deliberately used to avoid slowdown or dot crawl. for example Zelda II does this.

>> No.7922207

>>7922041
Some rom hacks are made with the idea the player will be using them.

>> No.7922297

>>7922190
SMB3 runs perfectly at 60FPS. What are you talking about?

>> No.7922320
File: 255 KB, 598x598, iwata.png [View same] [iqdb] [saucenao] [google]
7922320

>>7922190
Furthermore scrolling is absolutely free. You just write a pair of coordinates to the scroll register. That's it. Loading level data in four directions to the name/attr tables takes a bit more time, but, it's not significant compared to keeping track of objects. What takes up most of the horsepower is calculating a bunch of sprite positions and object hitboxes.

>> No.7922356

>>7922320
It's almost free if scrolling in the direction of the mirroring as you can move one complete screen before updating the tile map, if not in the direction of the mirroring it's slightly slower as each row has to be updated and there are graphics glitches at the edge of the screen.

>> No.7922369

>>7921820
>copies some core routines to the PRG RAM
you can also use that for some timing critical code, like preparing an unrolled loop to copy values to the CHR RAM at vblank

>> No.7922372

>>7922320
scrolling is a pain because you have to account for the attribute table

>> No.7922375

>>7921820
>but usually you have one fixed bank that contains core game routines as well as the banking code
Typically you have to include redundant copies of this code in multiple banks because ASIC mappers will just put any random bank in $C000-$FFFF at power on.

>> No.7922392

https://www.youtube.com/watch?v=5NWByyxT9ak

say in Renegade it manages the high speed scrolling in the motorcycle chase sections because the game uses V mirroring.

https://www.youtube.com/watch?v=VMJXZm21faY

Double Dragon is MMC1 but normally stays in H mirroring mode while scrolling horizontally so the scrolling is a bit less smooth and of course has graphics glitches.

>> No.7922402

>>7921820
>and some more advanced mappers let you switch in 8k pieces.
this is important in Kirby's Adventure btw, when you get a power up it switches in the object code for it

>> No.7922420
File: 58 KB, 769x791, somari.png [View same] [iqdb] [saucenao] [google]
7922420

>>7922356
>there are graphics glitches at the edge of the screen.
Yeah, it's unfortunate. You're basically stuck with horizontal mirroring and vertical scrolling without mapper help if you want 4 directional scrolling.
Somari, of all things, actually avoids the graphical glitches by just chopping off the bottom 16 pixels. You could also have extended RAM in the cart fill out all 4 name/attr tables.

>> No.7922454

>>7921365
Here's the version for old emulators like zsnes for example if it doesn't work
https://files.catbox.moe/ql558u.sfc
For some reason, they made 2 versions, one for emulators and one for real hardware/accurate emulators

>> No.7922470

>>7920190
I went back and beat it from the Tourian save.

>> No.7922475

>>7922420
>You're basically stuck with horizontal mirroring and vertical scrolling without mapper help if you want 4 directional scrolling

Some games like Zelda switch the mirroring as needed, depending on what direction the screen is moving in. This is usually when you have an open game map where you're moving in any direction Others like Double Dragon mostly just scroll horizontally with sections where they have to move the screen vertically so H mirroring is used the whole time to make the vertical scroll easier--in these kind of games action pauses during vertical scrolling.

SMB3 and Kirby have 8-way scrolling so they also just stay in H mirroring the whole time.

>> No.7922484

there's also single screen mirroring which some mappers support; for example Rare's AxROM cartridges. MMC1 also has an option for this, which MMC3 unfortunately got rid of.

>> No.7922514
File: 12 KB, 120x120, samus4_4.png [View same] [iqdb] [saucenao] [google]
7922514

>>7922475
True. Right i meant "8 direction" or 2 directions simultaneously.
Metroid is an elegant example of this, it switches the mirroring direction every door entry, and stacks the nametable addresses in such a way that it always works.

>> No.7922517

>>7922514
>mirroring direction
mirroring orientation rather. horizontal or vertical isn't really a direction.

>> No.7922536

>>7922514
think Dragon Quest where mirroring is switched on the fly--in the NES conversions which used MMC1. The Famicom DQ1 and 2 were UNROM and set to vertical mirroring so the graphics produce glitches when moving up and down.

>> No.7922537

>>7922475
Double Dragon seems as if it could have gotten away with UNROM, I'm not sure exactly why MMC1 was needed there.

>> No.7922542

>>7922537
the game has 256k of ROM and UNROM only supported 128k, no?

>> No.7922547

>>7922542
Granted, there was a version of UNROM that supported 256k but it wasn't used much and may have not been available yet when DD came out. However if you needed more than 128k of ROM it was considered better to just use an ASIC mapper.

>> No.7922632

>>7922537
> I don't know why X used advanced mapper Y when they could have gotten away with basic mapper Z
I see this post alot. Much of mapper choice has to do with what chips were in stock or being produced at the time. It's not just a technical question but a logical one: you had to physically make tens / hundreds of thousands of these things. Later games that were basic with unused mapper features couldn't just go back to basic mappers of the past that weren't being manufactured anymore because, well, they were not being manufactured anymore.

>> No.7922635

>>7922632
>logical
logistical. not logical. i am on fuckin fire today jesus christ[/spoiler[

>> No.7922647

Let's say I wanted to put up some money, like 100 for a bounty on a mod I want. How would I do that? See the Japanese version of Blue Stinger had fixed camera angles like classic RE, the western version had a behind the shoulder camera added and it's awful. If love the English dialog and text with the Japanese camera angles. Not sure how hard that would be

>> No.7922718

>>7922647
>Not sure how hard that would be
You really wouldn't know unless you tried it. It might be as simple as flipping the "japanese camera" bit. You might have to reengineer the entire fucking game. It's impossible to know until you get your hands dirty.
You could start by running both games in an emulator and looking for different bits that are consistent. You might get lucky.

>> No.7922746

>>7922632
Double Dragon was an early MMC1 game from 88 and discreet mappers like UxROM just use a TTL to switch the ROM banks, there's no custom silicon. most likely they needed to support 256k ROM and standard UxROM only supports 128k. there's also feature creep, if a developer wasn't exactly sure what they needed it was often better to play it safe and not use a more limiting cartridge setup.

>> No.7922801

ASIC mappers were generally preferred for their greater flexibility. usually budget games would have discreet mappers to reduce costs.

>> No.7922816

>>7922801
yeah a lot of Capcom Disney games used them. it seemed Capcom were cheaper than Konami because the latter's licensed NES titles were seemingly always MMC3 with big ROMs.

>> No.7922861
File: 94 KB, 540x720, Jeff-Foxworthy.jpg [View same] [iqdb] [saucenao] [google]
7922861

>>7921795
>>7921820
If an idiot agrees with you, you might be an idiot

>> No.7922871

>>7922718
How would I do that? I got more money than time. Would even put up 500 dollar bounty on it, maybe more.

>> No.7922874

>>7922861
both of them appear to be smarter than 5th graders. unlike you.

>> No.7922882

>>7922871
> dreamcast
you might have a tough time finding a place to spend it. there aren't many dreamcast brewers. try making a post here
https://segaxtreme.net/forums/

>> No.7922967

Any suggestions for a ROM hack that includes msu-1 support? I want to play something that feels like it could have been a SNES CD game.

>> No.7923208

>>7922874
See >>7922861
Also. Thanks for proving my point.

>> No.7924248

https://www.youtube.com/watch?v=nudtlNbdnu0

>> No.7924296

oot decomp is FUCKING HAPPENING
https://github.com/zeldaret/oot/

>> No.7924320

>>7922420
The Famicom was originally only meant to scroll in one axis and you could choose which one depending on how the cartridge PCB was wired. Scrolling in the non-mirrored axis is basically a hack. Then later of course ASIC mappers let you select the mirroring direction via software.

>> No.7924362
File: 27 KB, 480x360, mah_boi.jpg [View same] [iqdb] [saucenao] [google]
7924362

>>7924296
> oot decomp is FUCKING HAPPENING
indeed it is; and has been for a minute or two.
any new updates / milestones?

>> No.7924371

>>7924320
>Scrolling in the non-mirrored axis is basically a hack.
I'm not so sure. The scroll register is built to handle both X and Y coordinates. Being that the PCB seemed to be designed for 4 nametables with an unpopulated slot (and data lines to handle it in the cartridge) it makes me think scrolling in X/Y directions simultaneously was absolutely considered in the original design; even if it wasn't done with the early games.

>> No.7924424

The NES's mirrored nametables are an inefficient setup; the Master System and Gameboy, both designed later with the benefit of accumulated knowledge, don't mirror an entire table.

>> No.7924473

>>7924424
> designed later with the benefit of accumulated knowledge
i think cheaper RAM prices had wayyy more to do with it. an extra 2KB was a pretty penny in 1983 for a mass produced toy computer. the Fami / NES was in fact designed to handle 4 nametables: you just have to have extra RAM in the cart unfortunately.

>> No.7924562

>>7924473
Or even just disable the mirroring altogether and have a Master System-like setup.

>> No.7924703
File: 129 KB, 1743x794, cobra_triangle_title_nametable2.png [View same] [iqdb] [saucenao] [google]
[ERROR]

>>7924562
> just disable the mirroring
It's honestly not a bad idea. Use one nametable for the playfield and another for the status bar. Rare did all kinds of awesome shit with this setup.

>> No.7924839

>>7921648
You need to chill out or go back to /v/.
>>>/v/

>> No.7924863

>>7906293
Virtual Boy Wario Land enhance ported to N64.

>> No.7924974
File: 4 KB, 126x102, wario_thumbs_up.jpg [View same] [iqdb] [saucenao] [google]
[ERROR]

>>7924863
> Virtual Boy Wario Land
This game is Fucking Good. i would settle for any port to anything besides a mother fucking Virtual Boy.

>> No.7924980

>>7924863
> Wario Land 64
Someone made this demo almost 10 years ago and sadly never finished it
https://www.youtube.com/watch?v=hWVAxHsJQP0

>> No.7925925

https://www.youtube.com/watch?v=WWbZFj-cLvk

>> No.7927459
File: 253 KB, 1920x1052, seachase_21_7_5.png [View same] [iqdb] [saucenao] [google]
[ERROR]

>>7884406
Sea Chase SFX are all in place. I used an old sound register testing ROM that i modernized a year ago to design them. It was fun writing a custom sound engine. One more thing off the bucket list =)
I have the title screen song laid out in Famtracker, it's just a question of converting it to my custom sound engine now. The final product should sound identical(ish) but take up Much less space. This involves keying in all of the hex by hand. Should be a fun fun time...
Anyway, the damn thing is almost done! Hoping to release it next week or so. It's been 3 months, about a month longer than i thought it would take worst case, but doesn't everything always. I'm excited about how it turned out and equally excited to move on with my life at this point.
I'm pretty happy with the title screen song. It's very faithful to the original and yet has a bit more flare:
https://nesblast.com/music/Sea_Chase_-_Title_(NES_Remix).aac

>> No.7927478

>>7927459
the NES has a bit more sophisticated sound capabilities than the Atari 8-bit

>> No.7927487

>>7927478
yes indeed it does and i assure you i made good use of it =)
one of the things that frustrates me w/ Famitracker is that it doesn't use alot of the APU built in functionality. To be fair, it is very confusing and awkward to use. i would have been lost without the register testing program.
0CC Famitracker addresses this somewhat but it's still limited compared to the true power of the built in APU functions.

>> No.7927493

yes when you consider what Tim Follins did in Silver Surfer with crude 1980s tools

>> No.7927514

If we did this for the Master System, uggh it would sound like shit.

>> No.7927710
File: 129 KB, 800x600, GOOD SEX.gif [View same] [iqdb] [saucenao] [google]
[ERROR]

>>7927459
>those arpeggios
Sounds good, though.

>> No.7928317

https://www.youtube.com/watch?v=011UDCmNUnU

>> No.7928465
File: 22 KB, 413x550, 1618675034337.jpg [View same] [iqdb] [saucenao] [google]
[ERROR]

Someone redpill me on skyrim mods for switch cfw

>> No.7928629
File: 757 KB, 640x556, material test.webm [View same] [iqdb] [saucenao] [google]
[ERROR]

It's been a while since I posted some N64 stuff, so here goes:

There's now a text-rendering system, complete with unicode support. It's a little unoptimized, but the core functionality is there.

More importantly, the material system has been expanded to include many N64-specific settings. You can now, for example, set custom combiner equations, mess with the render mode, and even do multi-texturing. This makes it possible to hit the hardware more directly and really take advantage of the RDP's "powerful" capabilities.

And that's about it for now.

>> No.7928659

>>7928629
God I wish I could suck your dick anon

>> No.7928691

>>7928629
somehow, I feel like this could be a vaporwave masterpeice

>> No.7928731

Just saw this: Super Mario World 30th Ann. hack, still WIP but close to completion. Adding everything from Mario Advance 2, plus a Hard mode and potentially multiplayer co-op.
https://www.youtube.com/watch?v=YTQbXmbUszY

Im fucking excited over this. Hoping we get the same kinds of hacks later for Yoshi's Island (SMA3), SMB 1+LL (SMB Deluxe), and SMB3 (SMA4) especially.
Asides from the giant Shy Guys and warping sprites, does SMA1 add anything to SMB2/USA that wasn't already in the All-Stars version? And don't answer the voice acting.

>> No.7928996
File: 676 KB, 327x224, N64_get_N.gif [View same] [iqdb] [saucenao] [google]
[ERROR]

>>7928629
text looks great. full unicode is awesome. dat water tho hot damn 10 year old me would have exploded

>> No.7929143

>>7924703
some mappers support single screen mirroring, MMC1 does but MMC3 got rid of it unfortunately

>> No.7929186

>>7929143
that is very unfortunate. it's really a very nice feature for "8 directional" scrolling with a status bar, and probably the best way to do it from a performance standpoint without adding extra nametable RAM in the cart.

>> No.7930103

>>7906287
Some Sega Saturn homebrew updates:
https://www.youtube.com/watch?v=pqGQfCACK9I

>> No.7930204

>>7930103
I think the map he shows in this video is more visually pleasing.
https://www.youtube.com/watch?v=fJ_awpdw0C8
I was already impressed with everything he's managed to do with this game so far, but throwing multiplayer bots on top of that is somehow even more impressive to me.

>> No.7930974

>>7929143
Rare's AxROM setup was single screen with soft selectable mirroring direction. Though it didn't provide any IRQs so you still had to use sprite 0 hit for status bars.

>> No.7931329

>>7930974
scanline IRQs make split scrolling easier since it provides a more stable screen split than polling for sprite 0 hit

>> No.7931392

>>7931329
true, not only that, scanline IRQ is an interrupt so you don't have to stop everything you're doing in code and poll $2002 in a loop. it's nice to not have to design your entire game loop around the screen split.

>> No.7931404

>>7930974
Didn't they just have it so the whole 32k PRG is switched all at once?

>> No.7931413

>>7931404
Yes. It creates some issues with redundant code in each bank which wastes space and making it a bit trickier to use DCPM samples.

>> No.7931791

>>7931329
It depends somewhat on how the code loop is constructed but certain games like TMNT are very prone to the status bar breaking up when there's too much happening on screen.

>> No.7931974

this might not be the thread to ask, but I can't find anything related in the catalog. What's the best place to get NDS roms/emulators?

>> No.7931981
File: 367 KB, 360x242, SM_Cutscene_1.gif [View same] [iqdb] [saucenao] [google]
[ERROR]

Just a dumbass question but I figure you guys would know.
SNES can only rotate/scale backgrounds in Mode 7. Mode 7 also supports only one background.
What's going on in these cutscenes? This one is from the intro, but there are others at the end of the game. The ship is rotated/scaled but there seems to be additional background layers behind it.

>> No.7932030

>>7931981
I'm pretty sure everything is on the sprite layer in these scenes. That's how some of the boss rooms are handled in Mario World, too.

>> No.7932032
File: 806 B, 148x125, samus_stand.png [View same] [iqdb] [saucenao] [google]
[ERROR]

>>7931981
The ship is clearly mode 7. The stars appear to be one background layer, and the asteroids and the space station are probably sprites. This is just a guess: You could look in Snes9x or your favorite emulator and start enabling / disabling background layers to confirm this or tell me i'm full of shit =)

>> No.7932073
File: 1.24 MB, 853x480, sm_cutscene.webm [View same] [iqdb] [saucenao] [google]
[ERROR]

>>7931981
You were right >>7932030
Turns out the stars / space station / asteroids are all sprites. The ship and "SPACE COLONY" text is on mode 7 BG1.

>> No.7932297

>>7931791
>Because Gradius puts its status bar at the bottom, it can't just spin on sprite 0 all the time. Instead, it counts the approximate time that each object handler takes and deliberately delays the remaining calculations to the next frame when it might otherwise come close to missing a sprite 0 hit.

Note that TMNT has the status bar on the bottom not the top which complicates your coding a bit.

>> No.7932309

>>7932297
source for that gradius info? i'd love to read a write up

>> No.7932947

https://www.youtube.com/watch?v=fko68jYrBKY

>> No.7932952

>>7932073
>>7932030
Cheers anon!

>> No.7933802

Yup, the SNES can handle a full screen of sprites (about 280 sprite pixels per line) which is good for acting like another layer for things like mode 7 or graphics importing chips.
But that's best for stuff like display screens or cut scenes since that leaves very few sprites for objects on top of it, and there's some GPU bug that makes sprite exchange flickering near useless.

>> No.7933852

>>7932297
Also changing only the X scroll value is an eas(ier) operation with lots of leway comparted to the changing the Y value or both of them. It's one of the few things the PPU can tolerate well.

>> No.7933864

Is there any group that archives romhacks into a .dat file?

>> No.7933873

>>7933864
Check the copypasta for several romhack archives. If you know of anymore i'll include them next thread.
>.dat file
I don't even know what that is?

>> No.7933908

>>7933873
Rom managers use .dat files to match file hashes and identify files. They're used by a lot of groups like No-Intro, the MAME team, or the Total DOS Collection guys to validate roms. It makes it so you can turn a ROM manager loose on a folder and automatically locate any roms in a set.

A group called Retroplay has started doing translation patches, so they can distribute full validated sets of up to date prepatched roms. I'd like to have something similar for gameplay patches, but I don't want to embark on some big project if something like that already exists.

Were I to do it myself I'd ideally want to compile seperate registries for the prepatched roms, the patch contents, and the proper associated unpatched rom.

>> No.7933925
File: 9 KB, 250x231, sicp.jpg [View same] [iqdb] [saucenao] [google]
[ERROR]

>>7933908
i see so you're looking for a system of hash validated prepatched romhacks? i don't think such a thing exists to my knowledge.
romhacking.net does validate which ROM you need to use before you upload a hack though, and you as the patcher can verify that, it's up to you though to patch it from there.

>> No.7933949

Simple request. How about a hack for Eliminate Down where pressing the A button cycles Hough your weapons backwards. I never understood why both A and C just did the same thing.

>> No.7933969

>>7933852
>Also changing only the X scroll value is an eas(ier) operation with lots of leway comparted to the changing the Y value or both of them
huh? there's no difference in X or Y scrolling on the NES. not that I know of anyway.

>> No.7933978

>>7906293
The one I've always wanted was
>Pokemon Red & Blue
>On Crystal Engine
>with all the rumored stuff, like Pokegods, Mew under the truck, the Mist Stone, etc

>> No.7934069
File: 847 KB, 1000x700, von_neumann.png [View same] [iqdb] [saucenao] [google]
[ERROR]

>>7933969
> there's no difference in X or Y scrolling on the NES
Ohhhhhh yes there is. You can just write to the scroll registers in vBlank to denote a new position, but, if you change values mid-frame it gets a whole lot messier.
Changing the X value mid frame is pretty easy: you just write a new X value to the scroll register ($2005), and it just werks. Plenty of time to do it. Changing Y or both X/Y is much more complicated.
The PPU uses the ADDR ($2006) values to render the nametable, and keeps / increments the nametable value there. so, in order to change the Y value, you have to write the "top left of the nametable" value into $2006 and it will start rendering from the scanline you're at. You can't just write to the scroll register mid-frame: it doesn't compensate for the new nametable value, unlike in vBlank.
However: you can't just write in the new nametable value either. There are fine X and fine Y registers that actually exist in the PPU, each denoting 0-7 pixels from the offset of the nametable values. You end up with a combination of $2006, $2005, $2005, $2006 writes in this specific order so you get the X/Y scroll values you want where you want them. It's messy and extremely time sensitive. This isn't even getting into the various (sometimes documented) hardware bugs that fuck up your sprites / palettes when you fuck with the PPU mid-frame. That is a whole 'nother bucket of fun =)
https://wiki.nesdev.com/w/index.php/PPU_scrolling#Summary

>> No.7934079

>>7934069
I forgot to mention that all of these mid-frame PPU writes have to take place in hBlank (between scanline draws) and sometimes a specific piece of the already difficult to syncronize hBlank to avoid hardware sprite flickering / palette dropping issues that occur on hardware: they aren't emulated and aren't even completely understood yet =)

>> No.7934081

>>7934069
https://www.youtube.com/watch?v=qwfc5-sgllk

is that with a status bar or without because there are plenty of V scroll games like B-Wings with no status bar and this even has a little bit of diagonal scrolling.

>> No.7934090

Commando is one of the worst examples. It was the first NES game Capcom developed in-house and they had no clue what they were doing. It has ridiculous amounts of bugs and graphics glitches.

>> No.7934097

>>7934081
X/Y scrolling is cake IF you have no status bar (mid-frame X/Y changes)

>> No.7934108

https://www.youtube.com/watch?v=LF9HeIsELLs

that's why MMC3 makes everything better

>> No.7934120

>>7934069
>>7932297
Double Dragon manages V scroll in an MMC1 game (so there's no IRQ, only sprite 0 hit) and with a bottom status bar on top of it, along with active gameplay stuff happening (doesn't pause the action during V scroll). That must have taken some insane programming gymnastics and could explain why the game is so buggy.

https://www.youtube.com/watch?v=CTsyEnm3e6Q

>> No.7934128
File: 124 KB, 1826x793, kirbys_adv_status_bar.png [View same] [iqdb] [saucenao] [google]
[ERROR]

>>7934108
It does. the scanline interrupt is much more predictable than Sprite 0 polling: the margin that your code will run is much smaller. It's not perfect though: the CPU does have to finish whatever instruction is was doing before the interrupt triggers, and this can cause some variance, but it is MUCH less variance than the time it takes to poll $2002 for a sprite 0 hit in a loop.
So what though you might think? How much variance could there be? Well, one CPU cycle is equal to Three pixels, and when you're trying to run code in a space of about 60 undrawn pixels (hBlank), you don't have time for many instructions and the variance can really fuck up your shit. This is why many games look flickery in spots that they change X/Y scrolling. Few games get it right: Even SMB3 has some flicker on top of its status bar. Kirby nails it though.

>> No.7934134

>>7934128
It was, what, one of the first games to use MMC3? I suppose it took a while to figure out how to avoid scanline flicker.

>> No.7934150

>>7934134
Pretty much, far as i can tell. There are some nasty bugs that SMB3 avoids too, such as palette / OAM drop the way that it does turns off the PPU late. They made it a bit flickery but it was probably the right choice at the time: If you turn off the PPU too early, very nasty things occur on hardware and they still aren't well understood to this day.

>> No.7934156

>>7934134
Kirby avoids the nasty hardware glitches by not turning off the PPU at all and just moving the "camera" to where the status bar is in a very tight amount of time.

>> No.7934185

see the fun thing about C64 is that you can make the VIC-II do cool stuff it's not supposed to like VSP and border sprites do by experimenting with timing and register writes. on NES doing this just results in graphics glitches.

>> No.7934208

>>7934120
There's not much actual gameplay stuff happening during the vscroll near the end of level 2, just some sprites moving around.

>> No.7934214
File: 28 KB, 424x348, commodore_keeping_up.jpg [View same] [iqdb] [saucenao] [google]
[ERROR]

>>7934185
there are VIC revision issues there from what i understand when you start really mucking with it.

>> No.7934223

>>7934185
https://www.youtube.com/watch?v=TxrB0_6rSnc

Squish 'Em was a game we considered doing NES port of in /hbg/ but since it's vertical scrolling it might just be easier and make more sense to drop the status bars completely and use sprites for the score and lives counter.

>> No.7934228

>>7934120
someone ought to disassembly DD and find out exactly what the code is doing

>> No.7934269
File: 540 KB, 1634x1628, double_dragon_scrolling.png [View same] [iqdb] [saucenao] [google]
[ERROR]

>>7934228
interesting. the game is using horizontal mirroring, which isn't what you think it'd be using. it's loading all of the horizontal movement tile by tile into the 8x8 mask area on "the left side of the screen" as you scroll right. this allows it to use two stacked screens without penalty or moving the status bar or changing how the code works, which is how it's achieving limited vertical scrolling.
Many sidescrolling games like Super Mario Bros will use vertical mirroring and preload pieces of the screen into the unused nametable: this isn't the case here. the game does scroll slowly so it can easily get away with it.
i didn't delve into the code or anything but the PPU viewer here tells alot of the story.

>> No.7934306

LOZ used some kind of fuckery to scroll the screen up and it had to be completely rewritten to use sprite 0 hit when converted to cartridge because it would have originally used the IRQ on the FDS for the status bar.

>> No.7934326

>>7934269
>i didn't delve into the code or anything but
might provide some explanation for the millions of bugs in the game. two of my favorite ones:

>2:18 in the video I linked
that wall on the right side of the screen you can literally walk up
>Level 2 boss
you don't even have to actually fight that guy. When he comes out, walk back down the ladders until he's off-screen and the game will think you defeated him and advance to Level 3. I love doing that because I'm lazy and can't be bothered to fight him most of the time.

>> No.7934643

>SMB is probably the hardest game to emulate among the most popular NROM games, which are generally the first targets against which an emulator author tests his or her work. It relies on indirect JMP, correct palette mirroring (otherwise the sky will be black; see PPU palettes), sprite 0 detection (otherwise the game will freeze on the title screen), the 1-byte delay when reading from CHR ROM through PPUDATA (see The PPUDATA read buffer), and proper behavior of the nametable selection bits of PPUSTATUS and PPUADDR. In addition, there are several bad dumps floating around, some of which were ripped from pirate multicarts whose cheat menus leave several key parameters in RAM. If you're looking for a good first game for your new emulator, try anything made in 1984 or earlier, such as Donkey Kong.

>> No.7934678

>>7934269
I think the 1 in the 1P is Sprite 0.

>> No.7934692
File: 121 KB, 1610x789, double_dragon_spr0.png [View same] [iqdb] [saucenao] [google]
[ERROR]

>>7934678
Nope. It's this little guy right here. You would expect to find sprite 0 before the menu starts vertically.

>> No.7934713

>B-Wings, Fantasy Zone II, Demon Sword / Fudō Myōō Den, Fushigi no Umi no Nadia, Krusty's Fun House, Trolls in Crazyland, Over Horizon, Super Xevious: GAMP no Nazo, and Zippy Race. They write to CHR ROM and expect the writes to have no effect.
Copy protection check?

>> No.7934732

>>7910586
Awesome! 3do music please!

>> No.7934736

>>7934108
Crystalis does mid-line palette change (between the playfield and status bar I assume?) which is another tricky procedure, though maybe not as much here because MMC3 gives you an actual IRQ to play with. Some other games like Indy and the Last Crusade pull that off without MMC3 which requires some insane coding skills.

>> No.7934758
File: 28 KB, 512x448, 509567999.png [View same] [iqdb] [saucenao] [google]
[ERROR]

And TMNT not sure where sprite 0 is. The P in Pts?

>Teenage Mutant Ninja Turtles
>Uses Y scroll values greater than 239, causing the PPU to read the attribute table as nametable data before looping back to the same nametable instead of rolling to the next nametable down.

>> No.7934764

>>7934732
>Indy and the Last Crusade pull that off without MMC3
Right but it's also only the title screen where there is nothing else happening. It's not sooo bad to do it then.
There is another NES game that pulls off a mid-line palette change with no scanline IRQ. That game is Sea Chase =)

>> No.7934784

>>7934758
No. You won't find sprite 0 in the status bar, like i just said. >>7934692
It will be above it for a bottom status bar. You can look at the Sprite Viewer in Mesen to see what tile it is, or just open up the Memory viewer and look at locations $200-$203. Sprite memory goes: Y coordinate ($00), Tile ($01), Attributes ($02), than X coordinate ($03); and this repeats 64 times. A majority of games have the DMA sprite page at $200-$2FF; it's a fairly reasonable bet that it is there.

>> No.7934805

>>7934764
And Fantastic Adventures of Dizzy and Fire Hawk and Super Off Road. Some games also switch CHR tables in midline; eg. Pirates!.

These games also share something in common; they were all made by British developers. Presumably with C64 experience where trickery like this was commonplace.

>> No.7934809

>>7922967
There's the Jazzy Hip-Hop Earthbound one. I don't think they make too many hacks to the game itself, but it sounds awesome.

There's also Chrono Trigger Plus or whatever, which adds the video intro, and has a bunch of changes. I don't think CD audio is that good over the native SNES output though. The SNES music is absolutely amazing, and replacing that is blasphemy.

>> No.7934819

>>7928629
Looks rad, anon. You could have worked at Rare. Hopefully the end product has a nice framerate though haha

>> No.7934838

>>7934819
> Hopefully the end product has a nice framerate though
he has posted some of his demos with environments and models moving nicely at a smooth 30.

>> No.7934852

>>7930103
I remember this guy, he was the one who got bullied out of making Sonic Z-treme.
Good to see him pull this stuff out of the Saturn.

>> No.7934854

>>7934805
it seems Japanese developers were more conservative and didn't try as many l33t hax0r tricks as this.

>> No.7934861
File: 2.45 MB, 853x480, TMNT_spr0.webm [View same] [iqdb] [saucenao] [google]
[ERROR]

>>7934758
> TMNT
Whoa. This is a weird one. That right side of the screen right there? Masked with 15 8x16 black sprites LUL. Sprite 0 is one of those. I drew a yellow border on it.
No wonder this game is so damn flickery. I don't even know why you would bother masking this because most old CRTs would cut off these 8 rightmost pixels anyway, and it hogs up 1/4 of your sprite table.
Anyway, here's some fun with moving it about.

>> No.7934875

>>7933864
https://romhackdb.com/
This attempts to mostly do the translations, although its updates are slow & only considers the most recent patch.
This guy started a No-Intro renaming scheme for patches:
https://github.com/Earthsouls/RHTPP
https://discord.gg/MQqfErbDZZ

Hashing patches can be irritating, because multiple hacks are prepatched & each patching software makes a different version of the same format. So, each IPS software will make a different patch in which Floating IPS makes the smallest IPS & BPS patches to my knowledge. Some people, especially the Pokemon hackers, don't mention which version of the base ROM they used when making the patch. Some seem to use tools & decomps that only cover the v1.0 ROMs & then make patches with the v1.1/Rev 1 ROM. This increases the patch size by 1 to 6 MB depending on which format & software was used due to the official ROM changes.

In SNES cases, they'll either have a patch made where the base ROM was unheadered & they used a headered hack or vice versa which means the IPS file is around the same size as the base game. If you use the patch on an unheadered ROM & it adds a header, the hack was headered & the base ROM was unheadered. If you use it on an unheadered ROM & it doesn't add a header, but removes the header when the patch is applied to a headered ROM, then it was meant for headered, and not addressing this will not produce the proper ROM. If you use the BPS mode of Floating IPS with an unheadered SNES base ROM and a headered hack, it'll skip over the header, and the patch will produce an unheadered hack.

It's better to remake patches with the proper base ROM for accuracy & to save space. Using the proper base ROM will make a patch that's smaller than the incorrect one, and there's no use in maintaining multiple patches that produce the same ROM. A decent portion of RHDN contains incorrect patching info in the descriptions.

The Secret of Mana Turbo dev also uses the ZPS format that no one else uses.

>> No.7934887

>>7934861
Might that also explain using Y scroll values over 239? I'm sure it does explain why the status bar breaks up all the time. It might also depend on if the code loop runs off the NMI thread or the main CPU (LOZ for example is all NMI).

>> No.7934894

>>7934861
>I don't even know why you would bother masking this because most old CRTs would cut off these 8 rightmost pixels anyway, and it hogs up 1/4 of your sprite table.

Maybe they were testing it on a PVM-grade professional monitor or something with a square display and didn't bother accounting for normal consumer TVs because they were in a hurry to finish the game, which since it was a licensed title seems likely.

>> No.7934902

>>7906287
I want some good 2 players or co-op rom hacks for nes, snes, sega or whatever. besides super mario 2 player and tetris 2p , what else is there?

>> No.7934958
File: 2.63 MB, 853x480, NES_PPU_yScroll_invalid.webm [View same] [iqdb] [saucenao] [google]
[ERROR]

>>7934887
>Might that also explain using Y scroll values over 239?
No, that's something different and unrelated. The NES is 256x240, so, when you put 240-255 ($F1-$FF) into the scroll register ($2005) as a Y coordinate, the PPU becomes unhappy. It shows "pixels -15 to -1" at the top of the screen, which is erroneous junk from the previous Attribute table as Nametable data.
Here is an example of messing with the Y scroll value and demonstrating what happens when it is invalid: It just shows "garbage" at the top of the screen.

>> No.7934986

>>7934887
If i had to guess it's a "menu flicker reduction measure" so that the CPU has a little bit more time to process the frame. The menu still disappears when the game is busy, but, it would probably be a little worse if they didn't do that. You can see how the top few scanlines have some of that garbage data actually >>7934861

>> No.7934989

>>7934958
so is just sloppy coding that it uses Y values like that? i can't think of another reason for that.

>> No.7935002

Score bar breakup is not uncommon in a lot of games when too much stuff is happening; SMB for example has that issue and Double Dragon. I don't recall LOZ having that issue though, even in the dungeons with like 8 Darknuts on screen at once.

>> No.7935003

>>7934989
by moving the game down a few pixels, you have a tinyyy bit more time before the sprite 0 hit, so in theory the sprite 0 hit would miss less / menu would disappear less. that's my thought anyway. either way it's pretty sloppy, but, might actually be effective; you'd have to "fix" it and try running the game to see if there is a difference in menu disappearnece.
it's weird that they cared enough to cover up the right 8 pixels with 1/4 of the sprite table and didn't care about having a few junk pixels at the top. very bizarre.

>> No.7935014
File: 68 KB, 1200x960, engel_zelda03.gif [View same] [iqdb] [saucenao] [google]
[ERROR]

Status bar breakup is not uncommon in a lot of games when too much stuff is happening; SMB for example does and Double Dragon. I don't recall LOZ having that issue though, even in the dungeons with like 8 Darknuts on screen at once. Tons of slowdown but the status bar doesn't break up (that I remember, been a while since I played it).

>> No.7935026

>>7935014
The status bar static is an MMC3 bug. Only games that used the MMC3 memory mapper chip have that problem. Mario 3 is the prime example.

Zelda used an MMC1 which didn't have that bug

>> No.7935027

>>7935014
> I don't recall LOZ having that issue though
It never scrolls when there is any action. All of the scrolling is done in the "transition periods". The "breakup" only happens when the game is too busy to process the Sprite 0 hit because of other action happening, LoZ never has to worry about that because the screen is always "squared up" whenever the game is being played.

>> No.7935030
File: 69 KB, 960x1280, engel_zelda02.gif [View same] [iqdb] [saucenao] [google]
[ERROR]

also what the hell emulator did they use to make these? the colors are way off. it never looks like this on a real NES; it's an electric blue not this purple shit.

>> No.7935031

>>7935026
>The status bar static is an MMC3 bug
Not quite. It's the result of shutting off the PPU while the game is rendering. The "static" part is that it never quite happens at exactly the same time each frame.

>> No.7935038

>>7935030
Looks very blue on my screen. It's #4200ff. Probably looks a little lighter on real NES and a CRT.

>> No.7935065
File: 8 KB, 114x114, NESticle_hand2.png [View same] [iqdb] [saucenao] [google]
[ERROR]

>>7935030
> it never looks like this on a real NES
> no it's blue
> no it's purple
This topic is always a bucket of fun =)
The NES does not generate colors according to RGB, YUV, or even the NTSC standard; it basically "zaps" the NTSC colorburst and "tricks" it into generating colors: and it doesn't even do this correctly. It depends on how the TV interprets the wonky ass voltages generated by the console: some TVs the blues are purplish, some TVs the purples are blueish. Neither is more "right" or "wrong" than the other. Age / heat / capacitor life can throw the colors off too in both the TV and the Console. Fun times!
https://wiki.nesdev.com/w/index.php/NTSC_video

>> No.7935071

>>7935065
And for real fun times in Your Romhack: Use "black" color $0D: It is "blacker than black" and is close to the vBlank refresh signal and will cause a real CRT to lose horizontal synchronization and glitch the fuck out =)

>> No.7935075

>>7935065
That's a popular misconception, the NES used a fairly correct hue range.
Granted the luma wasn't as correct, was square waves and only used 2/3 of the dot crawl rotation (caused jagged color collisions) plus was about 10% brighter than normal, but that mostly screws with digital decoders that expected the final strict NTSC standard.

The problem was most CRT televsions did not perfectly follow the NTSC color decoding standard.
NTSC used a skewed hue gamut, more range was devoted to orange and cyan.
But many televisions used a cheaper more linear color decoder, this is why fixing skin tones would mess up the sky color & vice versa.
So the sky in SMB1 was indeed blue (though a light pure blue is a shade of Blue-lavender ($FF8080) , which appears slightly violet, but is not purple)
Also, these "accurate" palettes don't take into account most people had their TVs adjusted to strengthen colors such as red, yellow & sky blue.
Later consoles shifted the colors more in-between the standard and non-standard hues to look more consistent, but those still had issues that modern digital decoders dont like.

So the proper NES hues are: azure, blue, violet, purple, cool red, orange-red, orange, golden yellow, lime, green, aqua, cyan.
The cyan can throw people off, it's Mega Man's lighter color that people assume is supposed to be purely light blue, nope, it's that mana/neon cyan.
Well, the "reds" too, games had to choose between the cool or warm red. The yellows only looked right if used next to darker colors.

So in other words, there is no "perfect" NES palette because each developer had their own tint-shift they preferred.

>> No.7935079

>>7935030
it could be NESticle which had a notoriously wrong color palette

>> No.7935083

>>7935031
C64 games also suffer from frequent raster split flicker, although for an entirely different reason.

>> No.7935087
File: 93 KB, 1440x1280, engel_zelda06.gif [View same] [iqdb] [saucenao] [google]
[ERROR]

>>7935075
in three different CRT TVs and one flat panel that I've tried my toaster NES on, the colors were consistent on all but one of the CRTs and that was an ancient set from the 70s. that set seemed to want to display yellow rather than green which made the NES palette look way off. for example this dungeon was more of a golden color on that TV. cyan (eg. in the SMB underworld levels) was mostly blue and had a much reduced green component in it.

>> No.7935098

>>7935087
should add this dungeon was definitely a bit greener on my TVs with not as much red component as these screenshots

>> No.7935105
File: 1.57 MB, 2916x2236, trin_20210331_185524.jpg [View same] [iqdb] [saucenao] [google]
[ERROR]

>>7935087
Interesting. i've had issues with blues and purples on every different CRT i've tried on. Sylvania, RCA, Toshiba, a shitty Superscan, and finally a Trinitron recently. None of them can ever seem to agree. Hell, even composite and RF don't seem to agree either on the same damn TV!

>> No.7935115

The TVs I used were a Bravia and two 90s Thomson sets (I'd expect those to have the same color decoder) and a Panasonic color portable from 1978.

>>7935105
Never looked like that on any of these TVs. The sky was always powder blue not aqua (this looks more like the sky in SMB3) and the bricks were a dull rust color not this bright red-orange.

>> No.7935120

depends as well on what PPU revision you have since different ones can have slightly different colors

>> No.7935167
File: 131 KB, 775x621, 91dWtkRselL.jpg [View same] [iqdb] [saucenao] [google]
[ERROR]

>>7934108
>>7934736
the dialog boxes also switch palettes. however the game pauses while displaying them so changing the palette in hblank is relatively easy.

>> No.7935181

>>7934736
>>7935167
> Crystalis does mid-line palette change
Crystalis does not change the palette mid-frame. It keeps the text box / status bar colors in the 4th slot.

>> No.7935213

>>7935167
>changing the palette in hblank is relatively easy.
it is not.

>> No.7935235
File: 2.74 MB, 853x480, seachase_21_4_28.webm [View same] [iqdb] [saucenao] [google]
[ERROR]

>>7935167
>changing the palette in hblank is relatively easy.
It is not. First, you must determine when hBlank is. This has it's own synchronization issues. Then you have to shut off PPU rendering and set the PPU address pointer to the color you want to change. This is all of the time you have in that hBlank, so, you have to wait for the next scanline. The background color will be the color you are pointing at, so, consider that. While this line is rendering, load the new color you want to change and nametable address you want to restore into the A, X, and Y registers. Wait an appopriate amount of time. Then, when the next hBlank starts, write the new color to palette RAM and restore the nametable address to the PPU address register. If you don't do this in a vertical multiple of 8 then your Y address won't line up properly.
There. You changed one color. If you want to change more, you'll have to sacrifice more scanlines or accept a rainbowy mess drawing on the screen.
now you can properly appreciate how fucking smooth my shit is =)

>> No.7935239

yone have a patched ROM of Contra Hard Corps with these 2 patches one on gop of the other :

https://www.romhacking.net/hacks/797/
https://www.romhacking.net/hacks/450/

Been trying to apply both patches to the same ROM and after applying the second patch the ROM becomes orrupted and dorsnt work anymore on an original Genesis with a flashcart.

>> No.7935246

>>7935239
it may just not work. sorry =(
we had a discussion about it >>7915230

>> No.7935253

https://www.youtube.com/watch?v=3YcG2OnsvYM

Manhattan Project shows a major improvement over TMNT in the quality of the programming (so does TMNT II for that matter). They also manage flicker-free MMC3 screen split.

>> No.7935268

>>7935075
You copied that reply I made to a SMB1 colors thread a few weeks ago XD

>> No.7935741

>>7935239
No idea if that could help, but tried applying them in the opposite order?

>> No.7935818

>>7935014
Zelda was also originally a FDS game and the screen split would have used the FDS's IRQ generator. For cartridge conversion they had to switch it to use sprite 0 hit.

>> No.7935849

>>7929143
https://www.youtube.com/watch?v=xTonuqUL_MU

Earthbound has very clean 8 way scrolling on MMC3 but unlike SMB3 it also doesn't have a status bar.

>> No.7936003

>>7935246
that was my assumption but considering the author wrote that it was possible to combine both patches i thought it could be done.

>>7935741
yes i did, several times with different ROM dumps just in case my old early 2000s dumps were not good.

Anyways, whats the best way to play Contra Hard Corps for the first time? should i go vanilla Japan version or US version patched for multihit?

>> No.7936021

>>7935818
As was the case with Zelda II and that also has status bar breakup when too much stuff is happening.

>> No.7936045

https://www.youtube.com/watch?v=ENSwJx15vq0

yes, Commando on the NES is indeed an awful mess full of graphics glitches and even the screen momentarily blanking. Capcom really had no clue what they were doing at first.

>> No.7937175

bump

>> No.7937646

https://www.youtube.com/watch?v=xjvjeCibJ2Q

>> No.7937993

What're some real good DS and 3DS romhacks? Barring QoL patches for the DS Castlevanias and MegaMan BN5 & SF1, and fantranslations for Chibi-Robo Clean Sweep and Tingle's Balloon Trip, I haven't explored romhacks basically at all. I only just found out that NewerSMB DS, CTGP Nitro, and CTGP 7 exist.
What else is there that's worth trying out? I'm loving those last three in particular so far.

>> No.7938262

>>7937993
> DS and 3DS romhacks
There ain't much... There are 85 DS hacks listed on romhacking.net. I don't know if there are any 3DS romhacks: the system is a bit more locked down.
https://www.romhacking.net/?page=hacks&genre=&platform=23&game=&category=&perpage=100&order=&dir=&title=&author=&hacksearch=Go

>> No.7938778

>>7938262
3DS was blown wide open years ago. I never saw any ROM hacks that weren't translations though, except the Majora's Mask restoration hack.

>> No.7938813

>>7938778
In that case it still comes back to more complicated games are more complicated to hack. I seem to remember it being fairly difficult to jailbreak and run commercial games on? Also you're going to need emulators with dev tools, i'm not sure about the state of those.

>> No.7938836

>>7938813
>I seem to remember it being fairly difficult to jailbreak and run commercial games on?
Not any more, lol. Any 3DS can be hacked to pirate games now.

>> No.7938864

>>7938836
>Not any more, lol
Nice. Hopefully the romhacking scene catches up then. too young for my blood.

>> No.7939535 [DELETED] 

https://www.youtube.com/qoLW77whx7w
OH HELL YES

>> No.7939543

https://www.youtube.com/watch?v=qoLW77whx7w
NEW MELEE CONTENT HELL YES

>> No.7939816

What are good some good Homebrew or Hacks for the GBC?

>> No.7940108
File: 13 KB, 308x163, aaa.jpg [View same] [iqdb] [saucenao] [google]
7940108

I really want to get into nes dev. I learned a little bit of NES Assembly... but C looks way easier. If I just want to do something simple like a small DQ/FF style RPG will I take up too much space and/or have to figure out mappers?

https://nesdoug.com/
https://timcheeseman.com/nesdev/2016/01/18/hello-world-part-one.html
http://tuxnes.sourceforge.net/nesmapper.txt

also has anyone used this? honestly it just looks like assembly base projects
https://www.thenew8bitheroes.com/

>> No.7940190

>>7939543
Spent a few hours playing Beyond Gaylay online with rollback tonight. Its awesome! The balance changes are appropriate. The new characters like Wolf, Raichu, and especially Skull Kid are fun and fit right in.
The only real complaints i have are the new female announcer and voice acting are fucking terrible. Otherwise it is a very promising project.

>> No.7940886

>>7940108
C is not a viable idea on an 8-bit system. you're going to have to learn asm or gtfo. and yes you will have to figure out mappers unless you want to do Colecovision-level games.

>> No.7941047

C only became the norm in the 5th gen consoles.

>> No.7941070

>>7939543
>those horrible models
>the even worse animations
>stupid design ethos designed around changing the core of melee

sorry, who is this trannyshit for exactly?

>> No.7941354

>>7941070
rent free

>> No.7941590

>>7939543
Come back to me when they start properly backporting characters from the other Smash installments that AREN'T Wolf.
There are now two Wolves inside Melee.

>> No.7943027
File: 194 KB, 640x480, Dryrule Field.png [View same] [iqdb] [saucenao] [google]
7943027

oops it got all dried up
(you can now drag and drop images into the editor to replace textures)

>> No.7943034
File: 1008 KB, 1680x1010, 56291298191.png [View same] [iqdb] [saucenao] [google]
7943034

>>7943027
Here's what it looks like on the editor side.
Excuse the botched 3D viewport. It's not quite ready to handle proper emulation of the color-combiner.

>> No.7943236

>>7919227
>still no wario's woods SPC
>and there never will be
Lol

>> No.7943639

>>7943236
Nothing of value was lost.

>> No.7943938

>>7943935

new

>> No.7943942

new bread
>>7943929
>>7943929
>>7943929