[a / b / c / d / e / f / g / gif / h / hr / k / m / o / p / r / s / t / u / v / vg / vm / vmg / vr / vrpg / vst / w / wg] [i / ic] [r9k / s4s / vip] [cm / hm / lgbt / y] [3 / aco / adv / an / bant / biz / cgl / ck / co / diy / fa / fit / gd / hc / his / int / jp / lit / mlp / mu / n / news / out / po / pol / pw / qst / sci / soc / sp / tg / toy / trv / tv / vp / vt / wsg / wsr / x / xs] [Settings] [Search] [Mobile] [Home]
Board
Settings Mobile Home
/vr/ - Retro Games


Thread archived.
You cannot reply anymore.


[Advertise on 4chan]


File: 77.jpg (69 KB, 488x483)
69 KB
69 KB JPG
>be Nintendo
>ah we can't fit the pie factory on Donkey Kong NES because there's just not enough space we only had tiny-ass NROM carts back then
But these versions all had the pie factory in a mere 16k of space?
>>
File: IMG_0999(1).jpg (37 KB, 1170x678)
37 KB
37 KB JPG
FAKAU GAIJIN
>>
Weakest stage of the game anyway.
>>
>>12463273
They probably didn't code the game that well or efficiently but it would look bad to say it. Why else did they fit all four DK Jr. stages in the same ROM size?
>>
the NES release of Donkey Kong had a few differences from the original Famicom one, mostly bug fixes and some code routines were changed to be a little more efficient and thus execute faster. they also had a FDS release which had enough space for the pie factory but is still missing it, maybe they just didn't have the time or budget to add it in.
>>
I had assumed they were rushing it out, so the Sega SG-1000 wouldn't completely dominate the industry.
>>
>>12463459
the SG-1000 actually did better at first because of hardware issues with initial Famicoms and its games were also cheaper since they only used one ROM chip instead of needing two
>>
>>12463449
Early releases on a console sometimes make weird design or programming choices because the coders weren't familiar with the chipset yet or the initial versions have bugs or other issues that were worked out later. For one thing Japan didn't have many knowledgeable 6502 coders back then aside from HAL, and Nintendo had to outsource a bunch of stuff to them for that reason.
>>
>>12463273
There was technically more space since the NES cart had 24k total ROM while these had 16k to fit all game data and code in.
>>
>>12463273
They didn't own all the code because they retardedly outsourced the programming. They had to make it from scratch and couldn't finish it in time for launch.
They clearly could have fit every level on a base cartridge, because Donkey Kong Jr. had all of its levels.
>>
>>12463485
>They had to make it from scratch and couldn't finish it in time for launch.
i'm sure also issues with being unfamiliar with a new chipset+6502 asm. it seems in the early FC releases they also went out of their way to avoid the scanline limit, Mario Bros is coded in such a way to ensure no sprite overflow.
>>
>>12463508
there used to be a lot of complaining about sprite dropout in NES games so for the SNES Nintendo banned developers from going over the scanline limit (Sega and NEC didn't care though).
>>
Nintendo is done for this time
>>
My understanding is that both the PRG and CHR on Donkey Kong had some very inefficient use of their space and the game was not optimized well.
>>
>>12463483
Right. That was an advantage in the early days since they put the graphics in a separate ROM from the main one and got more space for additional game content, whereas on an SG-1000 a 16k cart was literally 16k, that was all the room you had.

Downside was costing more and not having rewritable graphics RAM for animated tiles and whatnot which you could do on SG-1000.
>>
There was a PAL only remake of Mario Bros. on an NROM-256 cart, it's a lot better game than the original NROM-128 version with all of the content from the arcade game and better physics. It works on NTSC NESes perfectly fine.
>>
>>12463536
in theory it would have been possible to have an NROM cart with CHR RAM that works like SG-1000 carts where you put the graphics in the PRG and copy them over as needed but nobody actually did it IRL
>>
>>12463570
I don't think you can also set that up on emulator, pretty sure you'd have to set an UNROM ROM and just only fill up 16 or or 32k while leaving the rest empty.
>>
>>12463273
Most people are confused by this one because NES DK has the levels in the order of girders/elevators/rivets since that was the order in the Japanese arcade game while most of the other home system ports are based off the level order of the US arcade game which went girders/rivets/elevators.
>>
>>12463483
they're also computers so they have plenty of RAM to unpack level data. was that the difference?
>>
>>12463273
donkey kong 64 version was the definitive edition anyways.
>>
>>12463750
I don't think that was the issue.
>>
>>12463485
Ikegami did all programming for them until Donkey Kong, they were like HAL before HAL. It was only after DKjr that they sued Nintendo and the relationship fell apart.
>>
>>12463905
it was a suit over ownership of the DK arcade source code and they settled in 1989 for an undisclosed sum

tl;dr is Nintendo did not have access to the arcade source code so the Famicom port was as much of a glorified bootleg as every Western computer and console port done by playing and memorizing a DK cab
>>
>>12463885
idk those early mapper-less games were extremely limited. NROM-128 games don't even have full scrolling, they're single screen or only scroll one screen width. you needed NROM-256 to have full scrolling.
>>
>>12463513
I've seen flickering on a bunch of SNES games I think that mandate is a lie (Konami stuff gets pretty intense)
>>
>>12463921
>NROM-128 games don't even have full scrolling, they're single screen or only scroll one screen width
Star Force does scroll though? the original Famicom version was NROM-128 and they upgraded it to CNROM for the NES release.
>>
>>12463513
I vaugly remember hearing from somewhere that was the case, but I just checked the leaked SNES Development Manual and it doesn't mention it anywhere.
>>
File: dk vs cb.png (192 KB, 1296x540)
192 KB
192 KB PNG
>>12463459
Delusion to think the SG-1000 was a factor
>>
>>12463946
I'd recommend the Famicom version because it's not quite as brutal as the US release, which is def. one of the hardest of all NES shmups
>>
>>12463273
This was the company that literally shipped nes carts with Famicom boards with some cheap converter and called it a day on the nes' launch. What do you expect?
>>
>>12464016
Congo Bongo shits all over Donkey Kong
>>
>>12464029
that was just Gyromite that used those lol
>>
As anon said, I think the main difference with the computer Donkey Kong ports is they had lots of RAM to depack game data while the NES had very little RAM so what was doable in 16k on a C64 was not doable on a NES.
>>
>>12464178
nah i'm still convinced it was a sloppy unoptimized port else how could DK Jr. fit four screens in the same ROM size?
>>
>>12463570
also the SG-1000 had a Z80 and Z80 code tends to be more compact than 6502 code. especially doing 16-bit operations on 6502 takes a lot of zero page transfers.
>>
>>12464039
there's around 20 or so titles with the converter inside

>>12464213
dk jr is 1kb larger and that 1kb would literally make a world of difference. i think the tl;dr: subcontracting & licensing is ridiculously complicated and nintendo paid dearly for it. it's possible they found an out in their shitty contract that allowed them to clone an already existing version from another platform, probably colecovision or a version that also has that missing level.
>>
>>12464247
>dk jr is 1kb larger and that 1kb would literally make a world of difference
beg your pardon?

https://nescartdb.com/profile/view/1091/donkey-kong
https://nescartdb.com/profile/view/912/donkey-kong-jr
>>
BTW I checked out Pooyan on C64 and it's 31k but the Famicom one was able to fit in an NROM-128 cart. This game had three stages. So I also guess the C64 one was not optimized that well because it's much bigger than it needs to be.
>>
>>12464337
Ron Gilbert was surprised they managed to get Maniac Mansion to work on the NES because he knew how difficult it had been to get it to fit on C64. He also considers it the best version of the game.
>>
>>12464815
the C64 game probably could have been programmed in a more efficient manner as well
>>
On AtariAge they had a ROM disassembly of the A8 Donkey Kong so you could look at that and see how it compares to the NES code.
>>
>>12463273
the general rule for most home system ports (certainly all the Atarisoft ones) was:

>Pac-Man 8k
>Galaxian 8k
>Dig Dug 16k
>Defender 16k
>Donkey Kong 16k
>Ms. Pac-Man 16k
>>
>>12465247
https://gb64.com/game.php?id=4860&d=18&h=0
I think the extra length is from the crack screen intro and other added features. The original A8 Miner 2049er was a 16k cartridge and there is no reason to suppose the C64 port was bigger in its unaltered form.
>>
>>12463483
https://www.youtube.com/watch?v=u6BI98RunMI
here's Popeye on the Atari 8-bit. this does look cruder than the NES Popeye. of course there was less ROM space since the NES had 24k of space while this was a 16k cartridge. the space savings from not having to put compressed graphics in the ROM or including a de-pack and copy routine were significant.
>>
>>12466486
>the space savings from not having to put compressed graphics in the ROM or including a de-pack and copy routine were significant
about how much more?
>>
>>12466493
I estimate an extra 3k of space, and on an 8-bit machine that accounted for a lot. On an Atari 800 cart the ROM has to include:

>all graphics data, which is stored in a compressed format
>a routine to unpack the graphics and copy them to RAM
Since the NES had its graphics in a separate ROM all the PRG space was free for additional game content. Which is among other things why it was inexcusable to not have all four Donkey Kong stages since there should be more ROM space than what any of the computer versions had.
>>
>>12466503
It's especially pathetic bc the whole point of the Famicom was to have an arcade-accurate version of donkey kong
>>
>>12466503
Should add that magnetic media games usually had no packed graphics, it wasn't needed and they just stored raw data. Some games especially with bitmap mode used vector graphics because bitmaps take a lot of space. I know Jumpman did that, there's a disassembly of the game and the bg graphics are all drawn via commands in the code, there's no actual stored data except for the sprites. Keep in mind that Jumpman on the Atari 8-bit did use bitmap mode, it was not a character mode game.
>>
>>12466451
It's bigger because that was a cracked/dumped cartridge with the graphics unpacked to be raw data.
>>
>>12466503
Wasn't there an official eShop re release for an anniversary a few years back that added the extra level back into the nes version?
>>
>>12466503
SMB uses essentially all PRG space, it was fucking shoehorned in there and could not have been possible if they also had to put the graphics in the ROM.
>>
>>12466563
now CNROM games get more space than NROM because they usually move the level data to the CHR ROM so the PRG has an extra couple kb of space for other stuff. there are also larger mapper games that put the level data in the CHR ROM, you can usually pick these out because they have a larger CHR than PRG. for example Night Rider and the two Flintstones games.
>>
File: 1760222973127290.png (41 KB, 400x167)
41 KB
41 KB PNG
>download a rom of SK NES with the pie factory included
>but its the second stage for some reason
>the barrel algorithm is always the same
>>
>>12464036
no it really doesnt
>>
>>12466503
>all graphics data, which is stored in a compressed format
A typical compression routine can reduce the graphics size by about 30%. You can't go too far with packing graphics because it will take gradually longer and longer to unpack them the more compressed they are and the unpacking routine will also get longer. It's a strange paradox that the more you compress graphics, the more code is needed to unpack them.
>>
>>12466594
CHR RAM NES games usually have compressed tiles in the PRG, if you dump the ROM they're not readable the way CHR ROM data is. This is also true of Gameboy games although some of those I thought do have raw tiles. For 16-bit games compression is near-universal because tilesets can be huge--a single SNES tile set can take up to 32k in its raw format.
>>
>>12466594
That relates to the idea of Kolmogorov complexity
>>
>>12466556
Yes. It's kinda neat to mess around with a little, but it's no good for high score play. The upper conveyor always goes in and never changes direction, and the conveyor speed increases as difficulty goes up. Eventually you can't outrun the conveyor and you're forced to jump towards the edge of the screen to get to the top ladders, so it becomes a total crapshoot if a pie happens to appear under you or not.
>>
>>12463273
They added the π factory... eventually.
>>
File: 1000101061.jpg (324 KB, 1627x1220)
324 KB
324 KB JPG
>>12467120
Whoops, forgot my image.
>>
figuring out ROM sizes on NES are a bit of a devil's errand because there's so many different configurations like UNROM (128k PRG CHR RAM), SLROM (128k PRG 128k CHR), SNROM (256k PRG CHR RAM), etc. and each is slightly more capacity in small increments. on other consoles it's simple, there's just 32k, 64k, 128k, etc in neat power of two increments.
>>
>>12467129
I think there were several shitty late period NES games that were Gameboy copypaste.
>>
>>12467145
yes they were usually UNROM carts because it was easy to convert from the Gameboy. stuff like Best of the Best Championship Karate. the Gameboy also lacked an exact equivalent of NROM-256 or CNROM, the two smallest ROM sizes were 32k and 64k but they were the normal compressed tiles stored in the ROM setup without the separate graphics ROM and raw tiles. so sometimes for ports devs had to make compromises. Dr. Mario on NES was CNROM but for Gameboy it was a 32k cart which had less space/capability (since only 32k to store all the game data). they could have used 64k but i guess Nintendo wanted to be as cheap as possible.
>>
also you had those games with the level data moved to the CHR ROM. one example was Roger Clemens MVP Baseball. on NES this was 128k PRG 256k CHR. for the Gameboy port they used 256k as a compromise.
>>
https://nescartdb.com/profile/view/4773/bible-adventures
some unlicensed games such as Color Dreams ones had 64k PRG and CHR which was a setup none of the licensed carts ever used
>>
>>12467231
>some unlicensed games such as Color Dreams ones had 64k PRG and CHR which was a setup none of the licensed carts ever used

No point in that when you could just use UNROM instead which had more space. CD were an unlicensed dev with very tight budget constraints so they had to use what was cheap and offered adequate enough space for their games.
>>
>>12467185
>Dr. Mario on NES was CNROM but for Gameboy it was a 32k cart which had less space/capability (since only 32k to store all the game data)
most of those 32k Gameboy carts have only one tile set because space was limited
>>
>>12467185
>they could have used 64k but i guess Nintendo wanted to be as cheap as possible
CNROM carts usually have three tile sets and bank 4 of the CHR ROM contains the level data. I think most of those 64k Gameboy carts have two tile sets which of course are compressed.

>two 16k code banks
>the other two 16k banks have the level/music/graphics data



[Advertise on 4chan]

Delete Post: [File Only] Style:
[Disable Mobile View / Use Desktop Site]

[Enable Mobile View / Use Mobile Site]

All trademarks and copyrights on this page are owned by their respective parties. Images uploaded are the responsibility of the Poster. Comments are owned by the Poster.