/vr/ - Retro Games

>>7070456
>we
>>>/r/eddit

>>7070456
The main problem is that you're clueless. Learn how to do a simple demo to move a sprite around the screen before thinking about doing a game. And before talking about thinking about doing a game learn what things are called so people know what you're even trying to say. Finally if you want "we" to do anything then you're going to need to bring something more to the table than a bad idea.

>>7070906
>The main problem is that you're clueless. Learn how to do a simple demo to move a sprite around the screen before thinking about doing a game

tbqh we have no idea what the OP's coding skills are

>>7071221
The guy you're replying to is the assembly language LARPer. Surprised he didn't yell about Dunning-Kreuger.

>>7071272
idk what he is but he sounds like someone's mother scolding you

>we
People who code shitty demos of a single sprite moving around with the dpad come and go all the time despite their grandiose promises. Put up or shut up.

>>7071221
>tbqh we have no idea what the OP's coding skills are
>and its controller has a D-pad with eight directions
I'm guessing none

>>7071331
>People who code shitty demos of a single sprite moving around with the dpad come and go all the time despite their grandiose promises.

https://desuarchive.org/vr/thread/7062304/#q7066946

Not sure if samefag or guy who just decided to lift the wording of this post. Still rude either way.

>>7071335
>and its controller has a D-pad with eight directions

The NES version of Archon has 8 directional firing and shooting, although it's kind of a PITA.

>>7070456
>Maybe a Master System port would be better instead? You can use char sprites all you want with no stupid restrictions and its controller has a D-pad with eight directions.

Here's the problem with that idea.

https://www.mobygames.com/game/shamus

Most versions of the game are for 6502 systems. If you were to port it to the Master System, then you'd need to completely recode it for the Z80 while an NES conversion could reuse code from the C64 or whatever. There's only a single Z80 system it's on, the NEC PC-6001 and there's no screenshots of that version online nor is it available anywhere to download (that I know of anyway).

Not that you absolutely need it, but if a game already has an existing version on the same CPU, it makes your job a lot easier.

>>7070456
moving and shooting diagonally is a trivial problem

>>7071551
As I told him, Archon does it even though it's more annoying than it is on C64 or Atari 800 where you have an 8 directional joystick. You simply press (eg.) left and up at the same time.

>>7070456
you could start by making a robust disassembly of the game. DA65 is a really good disassembler that allows you to mark blocks, code, data, as you figure hem out and insert comments and so on.

Then you can redistribute the disassembly script without redistributing the rom.

one thing that annoys me about Shamus in particular is that it wasn't the same game from system to system. most of the time they changed things around while Archon is pretty much the same in every version. C64 has additional maze layouts, the IBM version has slightly different mazes, and the VIC-20 has only 32 rooms and another completely different maze. so which one do you use as a basis?

ok so explain again what's the issue with all the enemies and why the NES can't do it. i'm not clear on this.

>>7071601
The Atari original actually changed the bg color for the maze you're in--the Black, Green, Red, and Blue mazes all had a different bg color. This was left out of other versions of the game because they were on machines that didn't have as large of a color palette (the A8 has 128 colors total meaning in practice 16 colors at 8 different luminance levels).

Actually even Archon exploited the A8's gradient colors but they had to omit this from every other version of the game.

>>7071637
as the OP said, the A8 and C64 Shamus use char sprites for all of the enemies. why this doesn't work too good on the NES? because each 2x2 block of tiles has to share a palette. i can't think of too many NES games outside Gauntlet that use char sprites while they're used on C64 and Master System all the time. in theory i guess you could do it if you very carefully set up your graphics so the playfield area is all set to use the same color palette in which case you could move around char sprites freely without causing weird color fuck ups.

>>7071567
>>7071408
i'm glad they did put out an NES port back in the day so we don't need to be sitting on anonymous Chinese cartoon boards 30 years later debating about how we can make Archon for the NES

>>7071570
>you could start by making a robust disassembly of the game. DA65 is a really good disassembler that allows you to mark blocks, code, data, as you figure hem out and insert comments and so on.

Assuming he was going to do an NES port specifically and wanted to use the Atari 8-bit or C64 code as a basis. If he wanted to do a Master System one, that would necessitate totally rewriting everything from the ground up.

i take it this is small enough that we won't have to play with bank switching, no?

>>7071570
>without redistributing the rom.
it was a computer game. most versions of it were on magnetic media.

>>7070456
make a snes port
u don't even have to leave 8 bit mode

>>99463828
that's as bad as San Fran still clinging to the 60s since they haven't been musically relevant since then.

>>7071818
The Atari original was 16k. The C64 port was closer to 30k because it had all those extra optional maze layouts. The VIC-20 was 8k and had only 32 rooms. Rest assured you will not need a mapper for this.

>>7071545
>no Zedd Exx Spectrum port
didn't expect that

>>7071965
No there was no Spectrum version of Shamus which is a little odd though it would be pretty trivial if anyone wanted to.

>>7071965
No there was no Spectrum version of Shamus which is a little odd though it would be pretty trivial to make one if anyone wanted to. Archon, Lode Runner, Boulder Dash, and Montezuma's Revenge all had Spectrum ports but this game didn't. maybe they couldn't find anyone available to port it.

>>7071886
The idea (hopefully) was to make a 16k NROM game. If it gets slightly over that we might go to 32k. But no, we're not gonna need banking.

wasn't there a guy talking about doing Gateway to Apshai in some earlier thread?

>>7072081
I remember that. The conclusion was that it would be a complete bitch to do because of the controls--it's designed for keyboard controls and the Colecovision could get away with it because it has a numpad.

>>7070456
Im the zniggy gb guy and progress is slow (i am a terrible dev) let's see who finishes first
good luck and godspeed

>>7072094
Like anon said, this is a bit more modest undertaking since the Atari original was a 16k game and we prolly won't need to use bank switching. Still impressed at the guy who did Prince of Persia for C64, even if he made some design choices they probably wouldn't have done back in the day.

I'd really like to see Jr. Pac-Man for the NES. I imagine it would be something like the Tengen Ms. Pac-Man.

>>7072129
sounds cool, but it does have scrolling mazes. Shamus has no scrolling which would make everything infinitely easier.

>>7072153
yeah you also don't really need to worry that much about what mirroring to use. just set either H or V mirroring, it doesn't matter.

>>7072171
Namco's early NES games would usually scroll the title screen on start up in whatever direction the mirroring happened to be set to. Could be either horizontal or vertical.

the 6502 is an absolute ass to program for

>>7072193
It can be. The NES is actually worse due to its lack of BCD mode.

just code it for the Master System. that would be much much easier.

>>7072209
code it for DOS

enjoy that cga mode i tried for zniggy lmao

>>7072193
i like any cpu with a flat address space and no legacy compatibility shit

so 6502 > 65816

>>7072216
Don't have to. That was already done back in the day.

>>7072209
We could, just suggested the NES as we have an easily available 6502 code base to work from while there isn't one for the Z80.

>>7072228
looks like shit, why am I not surprised lol

>>7072267
https://www.youtube.com/watch?v=GUyhiUKcSH8

It's ok. This version is also hard as hell because the enemies are very fast and mobile while in many of the 8-bit versions they're more static and don't move around as much.

But bless their little hearts, they actually gave you a pause feature which none of the 8-bit versions had.

>>7070456
>Zniggy
sounds racist

>>7071726
https://www.youtube.com/watch?v=tMKiOeZGTnU

Or just have it like in the VIC-20 version where the enemies are basically static and just sit in place and shoot you.

Fun fact: One of Synapse's games did appear on the NES, but it wasn't Shamus or Alley Cat, it was the much more obscure Dough Boy and it never made it out of Japan.

>>7070456
since we're here talkin about homebrew, i'm thinking I'm ready to try dealing with real hardware. I've got my carts socketed and ready to swap roms, gonna try some tests.

what's a good, inexpensive EPROM programmer suitable for NES/SNES carts?

>>7072485
>EPROM programmer
are you a time traveler from 1991? just get an Everdrive and put your homebrew ROMs on it.

>>7072389
>But bless their little hearts, they actually gave you a pause feature which none of the 8-bit versions had.
We will have a pause feature, don't worry. In fact it was actually mandatory back in the day to pass Nintendo's Q/C testing.

>>7072193
yeah the Z80 is way better and it takes less code to accomplish something. on average the same operation on the 6502 takes about 20% more code.

>>7072490
shut up fag

>>7072484
Synapse also died because of Jack Tramiel. Atari had commissioned them to produce software (forget what exactly it was) but after Jack bought them out, he pulled the plug on the deal and refused to pay them so they went bankrupt and were absorbed by Broderbund.

>>7071726
Shamus, the Shadow, and keys/potions whatever are sprites, and I assume your shots/the enemies' shots are as well. The enemies are all char sprites as you said.

>>7071846
SNES coding is like getting your teeth drilled with no anasthetic.

Don't like the C64 Shamus that much. It's buggy and also very brutally hard because your shots are so tiny compared to the Atari or the PC which makes it harder to hit stuff.

>>7070456
Anyway, the best way to deal with the enemies is to make sure the playfield (ie. the black area) has even multiples of 2x2 meta tiles so they can all have a common color palette. That way the enemies can move from metatile to metatile and not change colors. The NES has enough colors that we may actually be able to have the colored level bgs like in the Atari--just set the bg to the lowest luminance level.

>>7072449
ain't that a pity. the fucking VIC-20 could have animated bg tiles but the NES needed an MMC3 for that.

>>7072797
Or just use UNROM.

>ctrl+f
>"we"
>87 results found

>>7072987
>yfw most of those are from the date markers on the post indicating (Wed) for Wednesday

oh. never mind. lyl.

>>7072153
Instead of flick screen you could have the rooms scroll onto the screen like in Zelda. It may look a bit neater and polished touches like that were fairly common in NES games.

Nah just pointless work.

>>7073228
we really don't need to do that

>>7073228
Nah we don't need to do that. Just a lot more work for us. Flick screen is fine.

>>7071221
"We" don't because you have no coding skills yourself so are incapable of judging others. I do because I've coded for many systems. To be fair many people who haven't know that there's no problem doing diagonals with a NES controller and that "char sprites" aren't a thing. Most people can also count to 8 and 64, which OP obviously can't since he claimed his pic showed the NES couldn't display enough sprites to handle the game. And if you can't count to 8 you have 0 programming skills. You're just going to have to trust me on that one I guess.

>>7071545
>There's only a single Z80 system it's on, the NEC PC-6001
derp
>if a game already has an existing version on the same CPU, it makes your job a lot easier.
Only if you have decent source code and are too lazy/retarded to just do it from scratch

>>7072193
>>7072203
kids. lol

>>7072485
One that can program the parts your carts can use

>>7073551
>Most people can also count to 8 and 64, which OP obviously can't since he claimed his pic showed the NES couldn't display enough sprites to handle the game. And if you can't count to 8 you have 0 programming skills. You're just going to have to trust me on that one I guess

If you used 8x8 sprites (not 16x16 ones) you might get away with it, but if you had as many hw sprites moving around as the OP pic shows, you'd have _horrible_ slowdown (char sprites for comparison are cheap and take very little CPU time)

>>7073579
That GBC version should be disregarded entirely because the CPU in the Gameboy isn't a real Z80, it's a Frankenstein 8080/Z80 derivative that has significant differences with a real Z80.

>>7070906
Asshole

>>7073579
That GBC version should be disregarded entirely because the CPU in the Gameboy isn't a real Z80, it's a Frankenstein 8080/Z80 derivative that has significant differences.

>>7073551
>"char sprites" aren't a thing

Referring to using bg tiles as software sprites. They're extremely common in Master System games because the Master System makes it very easy to do. NES games don't do it that much because of how the color attribute system works.

https://desuarchive.org/vr/thread/7055226/#q7055226
https://desuarchive.org/vr/thread/7070456/#7074335

Did anyone else notice the Zniggy guy and all his posts got deleted?

>>7073551
>I do because I've coded for many systems.
Such as...?

ignore the assembly language LARPer

>>7072975
Sprite needs more work than that.

>>7072203
Seen a disassembly of Dragon Quest 1. Yeah there were some algorithms where they had to write needlessly complicated code to get around not being able to use decimal mode.

>>7074335
In the early part of the game you might be able to get away with it but eventually there's just too many enemies for the amount of hardware sprites you have without tons of flicker and slowdown.

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

>>7074335
In the early part of the game it could work but eventually there's just too many enemies for the amount of hardware sprites you have without tons of flicker and slowdown.

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

so enough talk. when do we start coding?

>>7075164
When the OP starts coding I guess.

>>7075164
>>7075242
>>7070456
OP pay me $500 and ill write you your scroll engine

>>7075326
This game doesn't have any scrolling in it. Not necessary.

>>7074471
really, what gives?

>>7070906
>>7073551
Again, we don't know what the OP's coding skills are or aren't.

How about the snail maze game from the Master System? That would be really easy.

>>7075669
very boring and there's hardly any game there

Might not be the right thread for this, but I updated the original Zniggy so that it has opening "music" and an ending once you collect 300 gems. Better late than never I guess.

>>7075825
Ok. Well apparently the Zniggy guy's posts all got deleted from the board for reasons unknown.

>>7070456
>Zniggy
I fucking hate you zniggers. Fuck off.

>>7074971
The barrier thing you have to shoot through I'm pretty sure is two wrapping player sprites. For NES this can be bg tiles and a solid black sprite moving down the screen could be used instead.

you need to have ninja reflexes to survive the later levels of this game

>>7075935
I've played mainly the Atari and IBM versions of Shamus and about halfway through the second level is as far as I've gotten.

>>7074335
Seeing as the NES doesn't have 16x16 sprites that wouldn't be an option. I'd have no problem with slowdown "_horrible_" or otherwise with that many sprites. With more shit on screen it could become a problem but as far as OPs claim about that pic, total bullshit. Again, "char sprites" isn't a thing.

>>7074385
>Referring to using words for something they don't mean
A dead giveaway that someone doesn't know the subject

>>7074553
2600, Coleco, NES, SMS, Apple ][ series, TI-99/4/A, VIC-20-Amiga, various TRS, Sinclair, CPM, PC, and minis, various NES, Sanyo, Sharp 4-8bit, various 6502, z80, 8080/etc devices. I think that just about covers it up to mid 80's

>>7075582
Again "we" don't only because "we" includes you. OP made it perfectly clear in the first post that he has no experience, can't count, etc. Again, just because you know even less than him doesn't mean other people can't tell.

>>7076052
>Seeing as the NES doesn't have 16x16 sprites that wouldn't be an option
surely he means metasprites like the large majority of NES games use?

>>7076070
That's the assembly language LARPer you're replying to.

>>7074971
>animated walls
>a bazillion enemies made with soft sprites
>eight directional movement and shooting
It's actually a bit impressive just how problematic an apparently simple game from 1982 would be to pull off on the NES hardware.

>>7076236
like someone else said, you can do 8 directional movement. Archon does it even though it's kinda annoying. actually i found trying to play the PC Shamus with the keyboard is hard to move and shoot diagonally as well. i could only pull it off with a joystick. i guess nothing beats the digital Atari sticks.

blump

>>7076262
never played it myself so can't comment

>>7077540
The NES Archon is also hard as balls because it's so fast. Dodging the unicorn/basilisk's shots are almost impossible.

>>7075669
The music is annoying.

>>7078085
Yeah it is.

So when's OP gonna get to work coding this?

This was on the GBC, wasn't it?

>>7078970
Yes

>>7073579

ok then

>>7078784
whenever he starts coding it i guess

>>7076070
This is a thread where OP wants to make a game but can't count and thinks the NES controller can't handle diagonal input. Don't call me shirley.
The 16x16 faggot thinks two dozen sprites (or two dozen "metasprites" composed of 4 dozen actual sprites) will cause "_horrible_ slowdown". How stupid of the engineers to design a system that can display 64 sprites when the system chokes on 48 amirite!?!?!?!?!
This is a shining example of why these threads are always shit. Know-nothing fools pontificating about what can't be done or should be done the wrong way and no one actually doing anything. Maybe if these absolute tools used that incredible imagination that allows them to believe they aren't just spewing utter shit for coming up with better ideas than "let's port a shitty game" one of them might shit out something useful.

>>7079340
beg pardon? Slowdown is very common in NES games eg. Legend of Zelda in certain areas with a lot of enemies.

>>7079340
It can display that many sprites on screen, don't mean you can move that many around at once on a 1Mhz CPU without everything slowing to a crawl.

>>7079340
>that incredible imagination that allows them to believe they aren't just spewing utter shit for coming up with better ideas than "let's port a shitty game" one of them might shit out something useful.

if you could actually come up with some better ideas than the OP's, we'd all like to hear it. or better yet if you could contribute literally anything useful to the thread instead of troll/spam posts. you won't of course because you're the assembly language LARPer.

ok so the top of your game ROM ($FFFA-$FFFF) has the CPU vectors. these are the reset, NMI, and IRQ interrupts. the reset vector contains the first address the CPU will go to on power on or reset. this is what will lead to your game's start/init code. the NMI vector contains the address the CPU goes to when an NMI occurs--in the case of the NES, the NMI occurs with the vblank. the IRQ vector is normally unused unless you have an advanced mapper like MMC3 with an IRQ counter. if you're not using that, you will want to have the IRQ vector leading to a PLA/PLP/RTI stub.

note that whenever an NMI or IRQ is triggered, the CPU disables IRQs so you will have to execute a CLI to turn them back on, but of course only if you're using MMC3 or something that has an IRQ generator, otherwise you're not ever using the IRQ at all and can just leave the flag disabled.

>>7080503
obviously this is going to not need a mapper or even scrolling so we don't have to fuck with the sprite 0 hit.

>>7080726
How about having the title screen scroll like Namco games did.

https://www.youtube.com/watch?v=9fLAjL1JhQo
https://www.youtube.com/watch?v=b5aDr4VESP8
https://www.youtube.com/watch?v=CKI7gzf496Q

>>7080905
>Dig Dug II
>a C64 port of...
Are you thinking what I'm thinking?

>>7080927
One game at a time please.

actually why didn't Dig Dug II get any ports but the NES one?

Not a popular game I guess.

I mean, I really don't think we need to have the rooms scroll onto the screen like one anon suggested. Just complicates the coding.

>>7081193
lyl probably not

>>7080184
>Slowdown
So we agree "_horrible_ slowdown" isn't a potential issue. Sweet

>>7080254
I can and anyone worth a pitcher of warm spit can move them around. You're pissing in the wind here kid. Have you even played the game on any platform ever?

>>7080315
>we
lol
>assembly language LARPer
I've seen this shit for a few years now and don't know who or what triggered you but your obsession isn't healthy

the nice thing about the NES is the separate CHR ROM which saves space in the main program ROM for other things (additional music, levels, etc).

>>7081658
Uh huh. Say SMB has 32k of PRG. Even with tile compression a couple kb of ROM space would be wasted on graphics data, but offloading it to the CHR ROM saves that space for other things.

bump

>>7081664

>>7071567
.. am I missing something here? Just press the d pad diagonally, up+left at same time, have you ever played contra before? Or if you mean moving to one direction and shooting to opposite, then smash TV nes port has that covered, it even has option to use two controllers to do so.

>>7081950
He's right though. The graphics data being offloaded in the CHR ROM frees up room in the main game ROM. On the Colecovision (for instance), some of the ROM has to be occupied by your bg graphics and sprite data. You also need additional code to copy it into video RAM, all of which takes room away from other stuff. With the NES this isn't necessary, the graphics are instantly accessible for the PPU and not using room in the main ROM.

what do you folks think of FORTH?
https://www.youtube.com/watch?v=g3HNhvW3lI8
https://gbforth.org/
this seems like a sensible way to get a basic "game engine" up and running with a language that's vastly more expressive than assembly

>>7082091
it's an 8-bit machine with 2k of RAM that requires cycle exact coding. HLLs are not gonna do the job here.

>>7082096
While true, the NES is somewhat more forgiving than the Atari 2600 which is truly a bastard to code.

>>7082096
>HLLs are not gonna do the job here.
do you understand what FORTH is and how it gets executed with indirect threading? it's only marginally slower than assembly and actually is more compact in memory. definitely not a high-level language. if you watch the video, they actually got the FORTH interpreter running on the gameboy, itself running the CHIP8 interpreter.

>>7082103
i've actually thought about if the 2600 could support some primitive subset of FORTH. the 128 byte ram limit is pretty insane though.

I remember seeing a video of a homebrew 4k NES game but 4k...that's just too fucking tiny. It looked like an Atari 2600 game with higher resolution graphics. Really, 16k is the minimum size to have something that looks like an NES game.

>>7082119
>i've actually thought about if the 2600 could support some primitive subset of FORTH. the 128 byte ram limit is pretty insane though.
it also has no video memory and your code loop has to redraw the playfield each frame.

>>7082125
>Really, 16k is the minimum size to have something that looks like an NES game
The Atari original Shamus was 16k and that's what we're hoping to go for here (16k PRG+8k CHR) though if it gets a little bigger that's ok. At least we will definitely not need to play with bank switching unlike the poor Zniggy guy who found that he can't pull his game design off on the Gameboy without it.

if that guy could make Prince of Persia for C64 (a much bigger, more complex game) we can pull off a little 16k NROM game.

>>7082129
That's why it's an interesting system to develop for. The TIA is alien, like a cross between a digital and an analogue device. Everything that came after it is more or less a variation on the same theme, but the Atari 2600 is unique.
>b-but it's too p-primitive for real gaming!!!
Nope. It just took something like 40 years for devs to figure out all the tricks:
https://www.youtube.com/watch?v=iWtN3bm_Hfw

the 2600 is also unique for having absolutely no input lag as the game logic and screen rendering take place within the same frame. on the NES and all other systems, it takes two frames to process the game logic and render the graphics thus there's always a one frame delay between pressing a controller button and the game logic acting on it.

>>7082148
wait didn't that game have an ARM chip in the cartridge as a coprocessor? I seem to recall it did. even though a few commercially released games did use enhanced cartridge chips like that (Pitfall II was one).

>>7082119
A few Atari 2600 games were programmed at least partially using FORTH if my memory is correct. It's for sure a good language to use for these early consoles.

>>7082091
Us guys think you watched a youtube that made you DK

>>7082139
"we're" just hoping tards like you will provide a little more entertainment with your fantasy role playing

>>7082148
It's only "alien" to a few hobbyist babies. Everyone else doesn't give a fuck or loves it. Just thinking about the sheer raw power it gives me over something called an electron gun gives me a semi.

>>7082159
>ackchyually DK: the post

>>7082303
Not sure, but I think you forgot to attach one of those screaming wojack pictures.

>>7082159
>on the NES and all other systems, it takes two frames to process the game logic and render the graphics

no it fucking doesn't

>>7082817
In fact most games on the NES would have more input lag than 2600. That is not because the NES is slower but because of the way games are coded. On the 2600 the cpu must be used during the active scan to update the display, on the NES the ppu does it for you. This means that on the NES the cpu is available for the entire frame duration to update the game state, and the actual render occurs on the next frame. With the 2600 the game state must be updated during the vblank period and during the active scan it must be used to update the display. That is why the 2600 has lower input lag because the engine and render occur on the same frame whilst NES they occur on separate frames.

For a typical game the code is implemented as follows.

frame 1:
1. v-blank interrupt
2. read controller for frame 1
3. update vram state frame 0
4. update game state: frame 1
5. sleep till v-blank

frame 2:
1. v-blank interrupt
2. read controller for frame 2
3. update vram state frame 1
4. update game state frame 2
5. sleep till v-blank

During the active scan the vdp renders the current frame and sends it to the television whilst the game code prepares the next frame. So in total it takes two frames for most games to respond to input. One frame to update the game state, and the next frame to render and scan-out to the television.

>>7082178
Not really. There are some 7800 games such as Choplifter and Karateka that were coded in Forth and they're not very good, in particular there's noticeable delay in responding to control inputs. The 6502 is really kind of crap in general for using HLLs on especially if you're coding an action game. If it's an adventure game or an RPG, you might get away with it but action stuff isn't going to work too good.

>>7071570
y'all can just get the game from AtariMania if you want to disassemble it

>>7083380
Ah, forgot about that.

>>7083129
now that I think about it you're right when you break it down

the last few scanlines would have near 2 frames of latency while the first few scanlines would have just over 1

>>7082303
>ackchyually DK: the post
retract this now

>>7082073
True live streaming of sprite data wasn't realized until MMC3. Some games however do switch in sprites between sections of the game, for example in Dragon Quest 1, it switches in a different group of enemies when you go over the bridges which is why there's momentary slowdown/lag while crossing them.

>>7083554
this probably wasn't as bad on the Famicom DQ1 as that used CNROM. the US version had MMC1 which is notoriously slow--it takes six instructions to bank something while CNROM only takes two.

>>7081616
>I've seen this shit for a few years now
I can answer that, as I'm the actual poster who created you. In fact, I can even link the thread. You took a fairly mediocre throwaway trolling that I did and made it your persona. The amazing part is that you're *still* running with it. It's actually kind of impressive.

>>/vr/thread/S4458748

I leave it as a fun exercise to the reader to determine how many posts I make (or even which posts are mine) before the "Assembly Language LARPer" is born unto the world.

>>7083570
>>7083554
Mega Man 1 also switches in different enemy sprites between level sections. That game is UNROM though so it's not really banking so much as it is copying the sprites into video RAM.

in theory i guess you could use CHR ROM with UNROM but it would be pretty stupid seeing as to how you'd only be able to have one graphics set. most of the discreet logic mappers use CHR RAM for this reason while the ASIC mappers can be used with either depending on your needs.

>>7082125
Galaxian was 8k. That was the only commercially released game under 16k.

>>7083720
technically Space Invaders is just about 9k. the ROM used is 16k but almost half of it is empty.

>>7074471
>>7075836
some angry jannie had an aneurism and deleted everything, i bet it was a discord outrage
anyway got some basic tiles down now

>>7074471
>>7075836
>>7083757
wtf? the posts from the original project got deleted from desuarchive?
how? why?

>>7083767
because some shmup fag had an absolute fit

bump

>>7083757
>pic related
Wow, exciting. it's getting somewhere.

C64 port of Battle City

>>7084426
not a bad idea and again a small game that wouldn't have any scrolling

>>7082534
that dude is absolutely mentally ill

bump

>>7084426
Neat idea.

>>7082534
Yeah never even seen that thread let alone posted in it. And damn, that's some serious psychosis you've got going on there. Better up your meds.

>>7084426
Maybe some other time.

yeah we haven't even apparently started work on this (as far as I can tell)

As I understand, the PPU has some kind of internal sprite RAM and you're supposed to copy the sprite data into there (?)

>>7086539
all the shitendo consoles have this

yeah you issue some command and it uses DMA to load the sprite data into the internal PPU memory area

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

Gauntlet uses char sprites. If they could do it, I'm fairly confident it would be possible here--you just have to pay careful attention to how they worked around the NES's color attribute restrictions--each enemy is a 2x2 metatile. I do agree char sprites are not used in NES games all that often.

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

Gauntlet uses char sprites. If they could do it, I'm fairly confident it would be possible here. You just have to pay careful attention to how they worked around the NES's color attribute restrictions--each enemy is a 2x2 metatile. I do agree char sprites are not used in NES games all that often.

In Shamus the enemies don't have about-face directions either so you won't need extra character patterns for those and risk running out of them (being that there's only 256 bg tiles)

>>7086701
>In Shamus the enemies don't have about-face directions either so you won't need extra character patterns for those and risk running out of them (being that there's only 256 bg tiles)

the Atari original uses char mode and that machine only did 128 characters so you'll be fine

>>7086701
yeah I'm guessing the OP understands the NES's (kind of bullshit) color attribute system?

>>7086701
It was possible to switch char sets in midline but is rarely done because of being insanely tricky to pull off. You can't touch the PPU during the active rendering so this can only be done during the extremely brief hblank (about 20-ish cycles on NTSC)

>>7086649
It's pretty easy. You load the low byte of an address into the OAM address register ($2003) , usually $00, and the high byte into the OAM ($4014) , usually $02, and 514 cycles later all of your sprites are magically copied into OAM RAM! $200-$2FF contains a copy of the sprite table in most games, as a de-facto standard. You want to do this every frame: if you don't, the cheap ass DRAM they used starts to decay and forget things. It only takes up 3(ish) scanlines of the 20 you have for vBlank, so, you have some time to do other things before the next frame starts drawing and the PPU is busy doing that.

>>7086771
>if you don't, the cheap ass DRAM they used starts to decay and forget things
Actually that's just because there's no RAM refresh capability in the console so you have to keep hitting the 2k WRAM each frame or it will lose its contents. Wouldn't be an issue if they used a Z80 instead as that has built-in RAM refresh.

>>7086728
> insanely tricky
it's not so bad, compared to other tricks. With the MMC3 scanline counter, its easy, just set an interrupt and when it triggers write a new value into the bank select register. Sprite 0 hit is a little more tricky, you have to make sure a non-transparent pixel hits another one, and sit there polling $2002 with BIT and BVC until the bit is set, but, the bank switching operation itself doesn't take long, so you have plenty of time to do it in hBlank.

>>7086795
yeah on the Colecovision and Master System you never have this issue as the CPU simply refreshes the RAM for you

>>7086795
> no RAM refresh capability in the console
The OAM (sprite) ram is dynamic and needs refresh, but the 2k of WRAM and 2k of VRAM doesn't. The palette ram in the $30xx range doesn't need refresh either, as far as i know... The NES is a quirky beast man.

>>7086814
I'm pretty sure the WRAM in both consoles is SRAM. The VDU uses DRAM and refreshes that each frame.

the PPU was something of a mess. Ricoh were not the neatest or most proficient guys around (seen by how the first revision SNES chipset is prone to self-destructing) and stuff like the 8 sprite per line limit was kind of accidental. they meant to display more sprites than that but due to sloppy design of the chip die the sprite display pipeline only has enough bandwidth for 8 sprites.

>>7086801
>but, the bank switching operation itself doesn't take long, so you have plenty of time to do it in hBlank
If you're using discreet logic mappers, no, but MMC1 is a slug--it takes six instructions to perform a banking operation.

>>7086801
MMC5/VRC6 would make it even easier as you have scanline interrupts.

>>7086864
> MMC1 is a slug
Avoid MMC1. Nintendo did: After MMC3 was a thing.
>>7086975
> MMC5/VRC scanline interrupts
MMC3 has scanline interrupts too! I'm pretty sure even the A revision does. Rev B/C is a definite.

>>7087070
>Avoid MMC1. Nintendo did: After MMC3 was a thing.

Too bad that MMC3 removed the disable mirroring feature from MMC1 which let you have a second nametable.

>>7087070
to be fair tons of third party games still used MMC1 for cost reasons especially if they needed a battery save. MMC3 was pricey so devs often didn't want to use it.

>>7087116
> third party games still used MMC1 for cost reasons
More or less because they already existed and were being produced. I can't think of a reason to use it today.

>>7087265
>I can't think of a reason to use it today
Maybe if you wanted the secondary nametable for some reason.

that's true

>>7087070
>Avoid MMC1. Nintendo did: After MMC3 was a thing.
Barker Bill's Trick Shooting, Mario Open Golf, and Tetris are MMC1 games that came out after MMC3 was available. Also To The Earth uses MMC3 for some reason although the game only has 64k of ROM. It may be the smallest MMC3 game ever.

>>7087765
>Also To The Earth uses MMC3 for some reason although the game only has 64k of ROM. It may be the smallest MMC3 game ever.

maybe they had a surplus of MMC3 chips they had to get rid of. the game doesn't appear to use any of the MMC3's capabilities except split screen scrolling. there's no animated bg tiles or anything.

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

>>7086771
It's a little more complicated than that. The OAM RAM is normally refreshed by the PPU each scanline, but during vblank or when the video is disabled, refresh stops and it will quickly lose its contents. On NTSC NESes, it is necessary for your code loop to rewrite the sprite data to the OAM RAM during the blank so it's refreshed properly.

PAL versions of the PPU actually don't need any OAM refresh as the timing of the vertical blank is different and it will still refresh the OAM during the active render even if you disable video.

bump

>>7083757
Not sure if an RPG is a good idea. A lot of homebrewers have made platformers or shmups but I have yet to hear of anyone completing an RPG.

>>7088520
never really thought about that but I guess you're right.

>>7088520
yep it will be a very short rpg

>>7088662
>yep it will be a very short rpg

so, like Hydlide.

>>7088691
I was thinking of having a proper combat system though, like dragon warrior or final fantasy. But yeah its super easy to have the scope go completely out of control with an rpg so that the game never ever finishes.

>>7086828
Coleco VDC uses DRAM refreshed by the VDC. SMS VPU uses SRAM.

sort of OT, but
That anon who kept whining about how good the genesis would be for this actually had a point, I realize, now that I've started looking into it. I don't know why I was originally so turned off to the idea (sonic maybe? idk). For months now I've been considering which platform would be best for /vr/ projects, but I think this will be my final choice.

Windows dev guide:
https://www.chibiakumas.com/68000/genesis.php

Linux dev guide:
https://log.martinatkins.me/2020/01/20/hello-sega-genesis/

Here's some platformer samples which stick out to me:
Contra: The Hard Corps
https://www.youtube.com/watch?v=nVQBVQeKjaw
Earthworm Jim
https://www.youtube.com/watch?v=49puptyIPVI
Decap Attack
https://www.youtube.com/watch?v=4YpxkphszDo

In particular I think "Decap Attack" has just the right energy, difficulty balance, and atmosphere to be a model game for "our" purposes. Sorry if this post causes even more speculation/procrastination btw. I'll make sure not to post again about this until I have something to show off.

>>7089243
oh yeah, that first link is more of a reference than a guide. here's a better one for windows users:
https://blog.bigevilcorporation.co.uk/2012/02/28/sega-megadrive-1-getting-started/

>>7089243
sure the genesis is good
but good luck creating all the artwork lmao

bump

>>7089569
this is obv. the biggest bottleneck with game dev

u are a fucking sperg and u can't make art

>>7090027
zniggy art is looking surprisingly good tho

come on, tons of Amiga games were made by 18-20 year olds and they had similar level of graphics to the MD

>>7088757
>But yeah its super easy to have the scope go completely out of control with an rpg so that the game never ever finishes
either that or you end up like Dragon Quest 4 where they spent an entire year just working on the AI which nobody likes anyway and there are nowadays ROM patches to disable it

>>7090227
fuckkk maybe i just keep it hydlide
this spriting alone is giving me headaches lol

>>7090293
wait, doesn't the Gameboy have hardware sprite flipping? You shouldn't need separate sprites for each direction he's facing.

>>7090312
yeah the stuff in the top left corner is all the sprites I use, the rest is just flipping and rearranging
the big problem with the gameboy is that the sprite ordering is raped by x-position, so it's pretty hard to design around that

>>7090312
>wait, doesn't the Gameboy have hardware sprite flipping? You shouldn't need separate sprites for each direction he's facing.

On the Master System you would have to do that, though in exchange you can flip bg tiles instead.

>>7088890
The Mega Drive then uses DRAM for the video. God only knows why.

>>7090351
the MD has 128k of video RAM. they used DRAM for cost reasons, also they're oddball chips that use a ZIFF package.

so what would be something inbetween hydlide and dragon warrior in terms of combat system?

bump

>>7090467
maybe

>>7086701
>char sprites

how is this different from a normal sprite?

>>7091573
it's using background tiles as software sprites

>>7091580
where can i read more on this?

>>7091590
there's not a whole lot to it. you just take some background tiles and shift them around the screen to create animated characters. the advantage is that character sprites are extremely cheap in CPU time to move around and you can have large amounts of them on screen with no scanline limitations. the downside is that they're choppy and can't do the fine movement of hw sprites and of course each char sprite you have means one less available tile for the background graphics.

on C64 and Master System, char sprites are commonly used. they're not seen on the NES that often because each 2x2 group of tiles has to share colors. Master System games particularly make extensive use of char sprites as it can have up to 512 tiles onscreen at once and is able to flip them to face up, down, left, or right.

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

0:27

the intro in The New Zealand story is entirely using character sprites, not hw ones and note the solid colored background so they can be easily moved around. the NES version is missing the intro entirely because the hardware simply wasn't capable of it.

>>7090357
I'm not familiar with the MD video circuit so I couldn't say. I'd guess it takes advantages of some features of the chips used though. It's not just plain old DRAM it's "video ram" dual port, etc.

>>7090357
>oddball chips that use a ZIFF package
Alright, you've have enough to drink buddy.
I don't recall ever seeing ZIP packages on a MD. But it was certainly popular on video cards around that time so wouldn't be surprised if Sega used them for some production. But definitely not exclusively.

bump

Bump, maybe this will go somewhere

>>7093594
You know it won't.

>>7094502
>>7070906
>>7071331
>>7081616
man, give up already

>>7094523
>no bully pls
back to le tiktok