/vr/ - Retro Games

They were much better for renting. So much dissapoint renting playstation games cause they were fucked up.

I think as objects they're a bit easier to appreciate aesthetically than discs, though I'm sure some will disagree and prefer the jewel cased CD.

I'd want SD cards.
I wouldn't want the carts back. Maybe make an exception if they looked really cool.

No loading times, easier to preserve.

And I don't know if we're going back to big carts, but cards like 3DS/Vita might be possible.
Maybe home systems could get bigger cards, like hu-cards from PC Engine back in the day. Except nowdays they could handle a lot more of space.

>>2470728
discs were better for renting for the pure fact you don't lose your progress if the disc is fucked you should know that before you walked out the door with it

Isn't the disadvantage true that eventually these cartridge based games will become completely useless? I guess maybe if they stuck around they would have been built to last much longer.

They was 'spensive as all fuck to produce, nyamean.
Only real downside.

They also had the potential for on-board enhancement chips: https://en.wikipedia.org/wiki/List_of_Super_NES_enhancement_chips

>>2470774

this applies to everything bro

>>2470724
Cartridges were more durable, which is important when you're making a game system where a large portion of the audience is going to be little kids.

I think going back to carts is worth thinking about. Flash memory technology is really maturing right now.

If cartridges make a return you can bet their biggest function will be DRM. These days the only thing that keeps you from being able to run most arcade games on your gaming PC is a proprietary card that the publishers jew techs design.

>>2470774
They're more durable than discs. Only concern with carts is the save battery

>>2470796
>>2470816
Save battery is what I meant. Those things die out much quicker right? I know I heard about Pokemon Gold and Silver having this issue because of the clock system in the game.

>>2470816
There's no reason a modern cartridge wouldn't use 500 year flash memory for its saves. A 256 meg flash bank probably costs less than a battery these days.

>>2470816
They were already using flash memory instead of batteries in many cases for the N64

>>2470825
Pokemon being one exception because Pokemon traditionally had a real-time clock that you can't change or fuck with in every cart. You still need a battery for that. Your Pokemon Yellow Pikachu knows you haven't loved him for 20 years.

>>2470724
Yes, quicker to read, more durable, aesthetically more pleasing to some, although big fancy cartridges won't be very viable so something like a hucard or what the psvita/3ds uses.

>>2470825
They need to be replaced like every 10-20 years. Keeping a small piece of SRAM alive uses almost no power. Running a clock circuit at all times will drain the battery pretty fast. Luckily most games don't have a real time clock

>>2470825
With on-system data storage and memory cards a reality, battery back-up need no longer be an issue. The bigger issue is as I said already.
>shit be 'spensive as a muhfugga, yo

Also, with everything being on the internet now, the clock could be handled according to that.

>>2470838
Boktai is the only series that comes to mind. I had to manual set the clock everytime when I played it recently.

Do the batteries inside carts leak?

>>2470849
I haven't heard of it happening before. Pokemon silver, gold, crystal, ruby, and sapphire use a real time clock but ruby and sapphire can still be played without the clock you just lose events and berries never grow

>>2470724
They had advantages over CD formats, in that the loading times were so short that you don't even notice them. However, often times things like sound quality and textures were laughably bad. But that was due to the limits on storage and not an inherent limitation of the medium in and of itself. So you could potentially create a cart that was large enough, file size wise, to correct any problems. And even add extra processing power to a cart, allowing consoles to play more advanced games.

The single most staggering disadvantage of carts in general was the fucking cost. In 1997, brand new PSX games cost $50, and many brand new N64 games cost up to $70. So that's quite a noticeable increase. And honestly just not worth it in many cases.

The other issue is that digital formats trump pretty much everything else, and the market is moving more and more towards that. The only down sides there being collectors hating digital (Boo-hoo) and buying a license or straight up being forced to be online to use a game. Other than that, digital has everything else beat in practical terms.

I'd be OK with the return of carts, but it'd be nothing but a gimmick, honestly. There's just no need for it and it offers no outright advantages that people REALLY want or need.

3DS and Vita... Well, cards, basically, are fine though. They function, save space and keep collectors from having a stroke.

>>2470724
>Meat Boy on a NES cartridge

why must indiefag hipsters insist on ruining the NES so much.

1.8" SSD size carts would be great. With SD card speeds to keep cost low.

>>2470806
>cartriges are more durable

Can confrim, I sent my dad into a drunken rage when I was a kid and he took a bat to my nintendo box. Everything survived. You can see the board in the metroid cart because there's a hole in it because of that, but it still works perfectly. Discs would have been smashed to shit, just like the metallica cd I had in there.

>>2470914
>Tfw you drop a disc on anything but shag carpet and the edge pits.
>Tfw when you drop a disc on shag and it scratches

Laserdiscs actually used optical media within a case. Though this medium went down as one of the hugest flops in data storage history.

>>2470968
Wait no, this was CEDs, my mistake.

>>2470724
All my cartridges still work. I can't say that for some consoles and many CDs. There you go. Even those ETs in the desert probably still run.

>>2470870
>I'd be OK with the return of carts, but it'd be nothing but a gimmick, honestly. There's just no need for it and it offers no outright advantages that people REALLY want or need.
Exactly. It's like the vinyl record of games mediums

>>2470884
Calm your tits. It's just a cheap edit.

>>2470724
they still use them on the 3ds don't they?

>>2470825

It's not like the cart is lost if the battery dies, and with the right equipment you can replace the battery.

>>2470968
>>2470970

Was gonna say...

For a modern caddied disc, look at UMDs.

>pixel art on NES cartridge covers

You're doing it wrong.

>>2471245

Everything will end up being downloaded or going back to solid state media. Retro kitsch has nothing to do with it.

We've reached the practical limit of optical density. Going to higher wavelengths for better resolution on the disc surface will only end up damaging the media.

>>2470724
SD cards maybe since a high class one can load fast and hold a lot. That was the good part was quick action.

Suppose just using internal SSD tech is better though.

I will say the creative ways cart space limitations affected games was awesome. Its mind blowing that Mario 3 with all its levels, power ups, and colorful worlds fit on one. I miss sprites. Not needing to texture map I guess is a large part of that.

>>2470724
Yes. Sony made a huge mistake in dumping the UMD in favor of carts.

>>2470870
There weren't any loading times. The games were run directly off the cartridge. That's the disadvantage of using any flash media or SD card. They still have to be loaded into conventional memory to be run. This is why, even on consoles like the 3DS and the Vita that use this method, they still have load times.

>>2471305
>implying

>>2471305

>>2472751
In the case of the N64 you're dead wrong about how games were run.

>>2472768
>>2472779
The OP has "pixel art". The first wave of NES games have stylized screenshots. There's a bit of a difference.

>>2470730
Isn't this what DS and 3DS games basically are?

>>2473072
http://www.ign.com/articles/2000/11/10/bringing-indy-to-n64

"The big strength was the N64 cartridge. We use the cartridge almost like normal RAM and are streaming all level data, textures, animations, music, sound and even program code while the game is running. With the final size of the levels and the amount of textures, the RAM of the N64 never would have been even remotely enough to fit any individual level. So the cartridge technology really saved the day." - Factor 5

>>2473261
yes, that's how cartridges work.

Some N64 games like Quake 64 actually did have loading times. Probably what they did was copy the c code which copied everything to RAM, and they didn't bother trying to optimize it to read it all directly from RAM.

>>2473265
>copy the c code
We're not all programing wizards such as yourself. Can you explain what you mean here?

>>2473273
I'm not a "programming wizard". It's fairly well known that the quakes were written in c/c++, and were famously released as open source by id software.

All I meant is that they may have literally copied the code and tried to modify it to work with N64 video/audio drivers and specs in the easiest way possible... which ended up with copying parts of the cartridge to RAM and loading times.

>>2473265
The only time cartridges on the Nintendo 64 worked the way you're suggesting is if they exceeded the size limit of the cartridge.

>>2473261
>almost like normal RAM and are streaming
Thanks for the link confirming N64 carts weren't run directly off the cart.

>>2476030
You obviously don't know how the system works or the difference between ROM and RAM. Here, let me tell you. First, things copied into RAM are never in the same place while thing in ROM are always in the exact same place. This is why the N64 is always looking at those specific area offsets. So, when you turn the system on the system executes the IPL boot ROM and copies the boot code (the cartridge) into RSP DMEM. At this point the main program code is DMA'd in the cartridge's header. This address in the cartridge's header is the boot address offset or program counter. This address is where the actual program begins directly off the cartridge. To keep this from getting to long, the CPU generates display lists that get dumped into DRAM which is made available to the RSP. And the rest is what you see on your screen. So yes. They are run directly off the cart.

>>2478568
But.. but.. memory mappers...

>>2470724
I love short load times. At least handhelds still preserve the tradition.
If I designed a console, it would take both blu-rays and some kind of flash cartridges or sticks, so you could publish a game on either one.

>>2473248
I think they're flash memory, which is why you can save to them.

>>2473265
Quake had load times because everything in it was compressed to shit so they could put less memory on the cart, saving money. The console has to decompress everything during the load screens.

>>2473261
Most devs were far from good enough to stream shit from the cart in real time. It was very hard on the N64. Most games would load big chunks off the cart at once.

>>2470728
>you will never go to a gas station or mom and pop video rental place and rent an NES game again

Of course cartridges had an advantage. You could shove custom game-specific hardware into each one.

Granted, that wouldn't really be beneficial outside of some extreme cases with modern consoles and PCs.

>>2478568
>things copied into RAM are never in the same place

Not strictly true.

>>2470724
>Would you ever want to see them back?
For what purpose?

>>2478710
for the nostalgia! lel we are /vr/trooper

>>2478568
As somebody with experience working with th N64 I can confirm you can absolutely not run code straight off the cartridge.

The bus bandwidth of the cartridge interface is considerably insufficient. Compared to the SNES, this bus bandwidth did not scale even close to the same proportion as the CPU did.

You can't execute anything until it has been copied into RDRAM. The best you can hope for with the N64 cartridge is a steady streaming of non-code assets.

Also the cartridge bus bandwidth is not considerably greater than the CD interface bandwidth on the PS1. The main advantage is cartridges have virtually no seek latency.

>>2470724
Cartridges had basically instant loading times. They however had less space.

Once games were expected to have large texture sizes and polygons it was no longer practical. This is ultimatly why Nintendo lost to sony. Any developer that put their games on Nintendo 64 had to gut 75% of the content. Rare only made games for them because they were contractually obligated. Hence why the n64 has almost zero good games not made by Nintend or Rare.

The only reason to use a cartridge would be for the instant loading speed.

Processors and RAM are a hell of a lot cheaper than they used to be. If you want faster loading times it's not too expensive (console manufactors don't do it though because loading times are never shown in trailers).

PC gamers always had the choice of buying a high end procressor and enjoying instant loading times.

So no there is no reason to ever use cartridges again.

>>2478896
Discs get scratched though. I don't understand why we don't go with SD cards in larger cases or something similar.

>>2478896
>. Hence why the n64 has almost zero good games not made by Nintend or Rare.

i`m not agree with you

>>2470884
I though they were just chinese bootlegs.

>>2478774
> As somebody with experience working with th N64 I can confirm you can absolutely not run code straight off the cartridge.

Experience working with the N64 = professional work that you got paid for or jerking around with technical docs and crap you got off the internet?

Also did you not read this post and what is your explanation of it if you're sticking to what you said?
>>2473072
>http://www.ign.com/articles/2000/11/10/bringing-indy-to-n64

>"The big strength was the N64 cartridge. We use the cartridge almost like normal RAM and are streaming all level data, textures, animations, music, sound and even program code while the game is running. With the final size of the levels and the amount of textures, the RAM of the N64 never would have been even remotely enough to fit any individual level. So the cartridge technology really saved the day." - Factor 5

>>2480134
>are streaming all level data, textures, animations, music, sound and even program code while the game is running

oh, that's just like sega saturn with it's separate cpu that handles cd streams

>>2480134
Homebrew directly, but indirectly working with people that did professionally program on N64

Also, Factor 5 was notorious at the time for their "tech PR" in which they would oversell their achievements, I'd seriously take any of their claims with a grain of salt. The most infamous example was when they released a comparison between the Gamecube and Xbox, and it was (almost certainly intentionally and) egregiously based on an extremely old Xbox prototype, just to rig it in Gamecube's favor. A conflict of interest considering they developed the dev kit audio tools for the console.

Anyway, the key words here are "almost" and "streaming".

>>2480079
We don't use SD cards because an SD card that could hold the 30+ gigs that some games are would be fucking expensive.

The extra money would either have to come out of the game's development budget (meaning less content) or the game would have to cost an extra $10 (and would sell less copies which means you need to lower the development budget)

The future of games is digital and that's a damn good thing. Digital distribution costs $0 meaning you can put 100% of the budget in the software instead of the hardware. More budget in the software means more and better content! It is also the only way that small budget or indi groups can get their games out.

>>2480268
Until some shitlord hacks your account and you lose everything.

>100% into software.

Maybe if you don't count advertising and other general overhead.

>>2480268
I hope we never get to the point where we have to rely solely on digital.

I like having a physical copy of something I own.

Plus there are plenty of places, even in the US, with spotty to horrible internet. Where I live I can only get a 3 GB wireless hotspot for my internet needs, and I wouldn't move just to game.

>>2483552
Because DRM is expensive to maintain there will always be unofficial ways to have physical copies.

You can take just about any game and put all the installation program on a DVD.

It won't come with nice cover art and your instruction book will be a PDF file though =/

>>2470816
More modern carts universally used flash memory. Example: Pokemon ruby/sapphire/emerald/FireRed/LeafGreen/Diamond/Pearl/Platinum/HeartGold/SoulSilver/(whatever came after that).

Ruby, Sapphire, and Emerald also had a battery but it only was used to keep the time, not to keep SRAM powered.

>>2480079
>Discs get scratched though
On blu ray it is almost impossible to cause a scratch that would interfere with reading data

Protip: when gamestop tries to sell you game insurance on your PS3 or PS4 game (does Xbone blu ray?) it is a scam. There's no fucking way that disc is going to stop working unless you deliberately fuck it up

>>2483583
or you have pets.

>>2483589
>Leaving discs laying around

Like he said, unless you deliberately fuck it up.

>>2483592
lazy people don't always deliberately leave something else. It just kind of happens because we aren't paying enough attention.

That said, I never buy game insurance and always make a backup to my computer. I've only had one disc ruined, but I was still glad to have a backup.

>>2483592
>>2483634
small children can open disc cases and wreak havoc.

>>2483637
They can also flush your keys down the toilet, hide your wallet in a garbage can, and piss inside your computer's case.

But you should be able to control your kids.

>>2483634
>Weren't paying enough attention

There's no point in time ever where the disc shouldn't be either in the console, in it's case, or in your hands.

>>2483637
This anon said it pretty well >>2483735

>>2473273
he means they had to copy the c to html codes and then compile it back to css before the n64 could read the x86 assembly back into dRAM

Cartridges are vastly superior for games. They're highly durable, have extremely low seek times, no moving physical parts. Battery save has been phased out long ago in favor of EEPROM (flash).
The only downside of carts is storage space. However, this is largely irrelevant. In modern games there are few space wasting assets, like videos and audio. You can slim down games extremely by getting rid of videos, using midi music and re-using textures better.
Price of cartridges is irrelevant for the publisher, since it's passed down to the consumer anyway.

>>2473261
>the RAM of the N64 never would have been even remotely enough to fit any individual level. So the cartridge technology really saved the day
That is an extremely misleading quote. The RAM of the N64 was low BECAUSE the use of cartridges allows to use them like "slow RAM". The carts did not save the day, they were part of the whole design. It's the same on handhelds.

A useful aspect of carts is also that they can contain additional hardware, where useful. If individual games need more RAM than usual, or special sensors and hardware, you add it to the cart, instead of burdening the console with it. Likewise it allows devs to develop games that may not fit the system hardware perfectly. Within reason necessary hardware can be added. Kirby Tilt'n'Tumble is a well known example. The GBC has no tilt sensor, and no use for it. Yet the game uses it, to great effect.
A more recent example is Pokémon typing. The NDS was too early to have bluetooth support. By the time this game came around though, they could add the receiver to the cart, giving the NDS capabilities that were not even part of the design. (apologies for using the NDS as a non-/vr/ example)

>>2478896
>Once games were expected to have large texture sizes and polygons it was no longer practical
Wrong. Meshes need very little size, and you can save a ton of textures by a) smart reuse and b) procedural generation

>>2478896
CPU and RAM do very little for loading times, at least if it's loading times caused by moving data from the disc into RAM. That stuff is entirely I/O (drive speed) bound. The solution in the world of PC gaming was the insanity known as copying the entire disc content onto the HDD during "install", and then requiring the disc in drive exclusively for DRM reasons. Meanwhile consoles, out of necessity, perfected data streaming from the optical drive.
Nowadays an SSD acts kind of like a cartridge, in terms of access speed, though there's still the indirection of the file system. A cartridge is typically memory mapped.

Modern reasons for cartridges are durability, simplicity of development and extensibility (still an issue for consoles, that need to last a couple years)

>>2485450
>a) smart reuse and b) procedural generation

Aka bad graphics and shitty artistic design.

You literally argueing that our artists LOWER THEIR OWN STANDARDS (by focusing on reusing assets instead of creating as many unique ones as possible) so that we can use fucking cartridges because the are nostalgic for you or something.

>>2485482
>bad graphics and shitty artistic design
Give me a handful of wang tiles over a couple GB of single use texture. Procedural generation outperforms manual creation whenever you're dealing with any amount of scale or are trying to imitate natural processes (vegetation placement, erosion, settlements)

>artists LOWER THEIR OWN STANDARDS
I am argueing that the artists get the hell out of the way of the game.
Artists are the retards producing non-interactive single use assets, wasting everybody's time, money and space.

>because the are nostalgic for you or something
More durable, faster, easier to code for, extensible.

You're argueing in favor of the realtime rendered equivalent of FMV games. A ton of single-use assets and forgettable gameplay (sandbox #4362 coming right up), with 90% of the game costs sunk into assets and marketing. I'm argueing in favor of actual games, that use assets as a mechanism to convey gameplay and game world. If that makes me nostalgic, then so be it. I'm on /vr/ here anyway.

>>2480268
>We don't use SD cards because an SD card that could hold the 30+ gigs that some games are would be fucking expensive.
Sandisk sells 32gb MicroSD's for $12.

>>2485496
BDs holding more than that cost mere cents.
Also, the price you pay in stores is not the production cost, or the price the publisher pays for it.

>>2480268
>30+ gigs
Take a look at the types of data that occupy that space. There's a lot of waste going on.

>>2485496
CD space/cost is less than that.

>>2485492
Your arguement is fucking pointless. Even if 50% of the textures in the game were procedurally generated (an insane number) it would still be a game that consumes tons of space

>I am argueing that the artists get the hell out of the way of the game. Artists are the retards producing non-interactive single use assets, wasting everybody's time, money and space.

You do realize you pretty much insulting every game ever made as well as pretty much every artist that ever worked on a video game.
You are literally saying that video games should gut their graphics budget, fire their artists, shrink the games down to a few megabyes of coding all so that they can fit into a cartridge and have slightly faster loading times.

WOW

>>2485617
>Even if 50% of the textures in the game were procedurally generated (an insane number) it would still be a game that consumes tons of space
You have no idea

>You are literally saying that video games should gut their graphics budget
Hell yes I am.

>fire their artists
No, just 90% of them. They contribute nothing to a game. They cost wages, strip away the opportunity for dynamics and their "output" wastes space.

>shrink the games down to a few megabyes of coding
They already are this small in terms of binaries. Waste from assets is huge.

>so that they can fit into a cartridge
Modern cartridges fit a couple hundred MB, up to easily a dozen GB.

>slightly faster loading times
What is latency? Large parts of modern game engines are concerned with streaming to cope with extreme loading times. BD drives have latency of a couple hundred milliseconds, carts are an effective zero. BD drives throughput is limited by the physical limits of rotating the disc and the analog-digital barrier of reading the disc. With a cart you can, if you're crazy enough, just expose a PCI slot and go straight for a couple hundred MB/s.

>>2485624
Digital distribution has even less latency and allows for even bigger files (the upcoming game Star Citizen for instance will be more than 100 Gigabytes at launch and get bigger every patch). You either do not know this or more likely you do know it but you still won't shut up about cartridges. Not because you honestly believe that getting "a few milliseconds of latency less) is the most important priority in video games but because you have some fixation with old technology.

Honestly if you were to fire 90% of the artists in any given game I don't think video games would have survived as a medium, or at least they would have never advanced past 1970s text adventures. I probably would have never touched a console if Link to the Past had shitty procedurally generated levels, neither would most people. Graphics and artists are necessary to create immersion. In other words if your idea was adopted video games would have died.

I'm actually working on an 'Indie' game myself. From a design perspective the idea that our artist shouldn't have made the flowers he did last week because there are 'non-intractable' is incredibly stupid. I could remove him from the staff like you suggest and create the entire game myself. You would play as a red square and all enemies would be different colored triangles. Hardly a good idea.

>>2485624
Programmercuck confirmed.

>>2486510
>Digital distribution has even less latency
Digital distribution was not even a subject until now, and its latency depends on your installed hardware. Cartridges are a console/handheld thing, not for PCs. Consoles and handhelds typically have very low installed persistent memory, so digital distribution is not much of an option. Even if it were, the memory used is usually HDDs, because it's cheaper.

>Not because you honestly believe that getting "a few milliseconds of latency less) is the most important priority in video games but because you have some fixation with old technology.
You have no idea how massively important speedy random access is for games, do you? All streaming and caching mechanisms in games exist merely to work around the speed issues that you shrug off.

>Honestly if you were to fire 90% of the artists in any given game I don't think video games would have survived as a medium
I fully believe if artists wouldn't have gained such a stronghold, we'd have a true variety of actual games, instead of a shitton of interactive movies wrapped around a sandbox. Modern gaming is in a very pathetic state, dominated by its non-interactive aspects (cutscene scripting, modelling)

>I probably would have never touched a console if Link to the Past had shitty procedurally generated levels, neither would most people.
LttP reuses textures to an extreme extend, thanks to a native tiling engine on its hardware. This allows for huge worlds with very little memory consumption. Notice that I did mention texture reuse as one mechanism. You bring up a prime example of texture reuse.

>>2486510
>Graphics and artists are necessary to create immersion
And to stay with your example of LttP, the graphics artists are but one group in the development process. The game lives because of its story, fighting mechanics and puzzles. None of these aspects are graphics related. I suggested to fire 90% of the asset staff. Yes, you do need an artist or two, skilled ones, to produce the graphics to make LttP puzzles looking good. You do not need a couple hundred artists to produce thousands of unique tiles to cover up the game world.

>our artist
Notice the singular. Again, I said firing 90% of the asset staff. What's your ratio of asset creators to scripters/devs/designers? In modern shops more than two thirds of the crew produce assets, and nothing else. That is bullshit.

I am not against graphics in games. I am against crude and simple game mechanics in interactive graphics sequences, claiming to be "games". That's what current games are. Because it's so much easier to produce assets, than it is to produce actual good games.

>I could remove him from the staff like you suggest
I did not suggest that. If your 10 folks indie project had 8 artists, a coder and an idea guy, you'd be in modern game territory, and I'd tell you to get rid of 6 or 7 of the artists.

>You would play as a red square and all enemies would be different colored triangles. Hardly a good idea.
The alternative is currently to watch a highly detailed character perform a crazy stunt after you press a button in a QTE. Hardly a game.

Cartridges will make a return, only they'll basically be high capacity SD cards. And yeah, they will be completely superior to optical media.

>>2487152
Graphics are themself non-interactable. The sprite or polygon on enemy does not impact the game's mechanic in anyway. It is only the hit boxes and the coding that says "when this hitbox is touched..." You can always go to making the protagonist a red square fighting different colored triangles like I said.

The art's job is to create immersion. The more money he has the better he can do this. The less he reuses assets the better he can do this. If Link to the Past was released on the PC it could have been a much larger game and they could have re-used assets less. In an ideal video game every single asset would be unique. Seeing things repeated enforces is anti-immersion which is anti-art.

Your point about consoles and handhelds is stupid because consolse and handhelds ARE pcs. Or rather they are extremely simplified PC'ed. From an artistic and design perspective consoles and handhelds are bad. The artist has to lower the polygon on his own models, the level design has to scrap ideas. (see the newest Doom game which had to lower the number of on screen enemies to meet console requirements).

> if artists wouldn't have gained such a stronghold

The "non-interactable movie" bullshit you talk about isn't a new thing. Old school adventure games were played entirely for their cinematic value. The 1 million cutscene jrpg was developed in the 4th generation with games like ff6.

The dominance of cut-scene and immersion focused games is a result of the increasing number of non-gamers that buy games.

>>2486510
>You would play as a red square and all enemies would be different colored triangles. Hardly a good idea.
You think so? Sometimes it is a good idea to think outside of the box.

>>2487203
>Those SNES cutscnes doe

>>2487203
>You can always go to making the protagonist a red square fighting different colored triangles like I said.
You're providing a false dichotomy and you know it. If you want to argue what I said, be my guest. If you want to tear down your strawman, don't expect me to join in.

>The art's job is to create immersion
The artist's job is to create assets that support the game. The shiniest textures won't create "immersion" if your NPCs stand around with a question mark above their head.

>The less he reuses assets the better he can do this
Disagreed. There's art in reuse, smart reuse, creative reuse.

>If Link to the Past was released on the PC it could have been a much larger game and they could have re-used assets less
You do not honestly believe LttP would gain anything from stripping away its tiles, which are key to its puzzles, and making the game world smaller?

>In an ideal video game every single asset would be unique
In YOUR ideal video game, maybe. I hope you are not representative of people interested in the subject.

I'm sorry, but I'm going to remove myself from the discussion here. I can not follow your claims at all, and a lot of them are off-topic. So we'll just have to disagree.

>The 1 million cutscene jrpg
Who said anything about JRPGs? Look at your latest cover based shooters, or your adventure sandbox of the week. They're full of QTEs, cutscenes and non-interactive content.

>The dominance of cut-scene and immersion focused games is a result of the increasing number of non-gamers that buy games.
It's the result of publishers being risk averse and doing "what works", which is minimal established gameplay, and non-interactive assets caked on top, to give the illusion of progress.
The non-gamers are a result of trying to broaden the audience, to recover the extreme costs of that development model.

>>2487171
>it's so much easier to produce assets, than it is to produce actual good games.

Ok you don't know shit about video game production.

I could string togeather a blueprint in a day for a Monster that walks around, looks for the player, and than tries to attack him.

If this monster were particularly advanced thing, like say a big Dragon it would take more than a week for the artists to make the damn guy. You'd need to make his polygon model, make the skeleton, rig the bones, make the texture, the normal map, the bump map. Don't forget animations! That's a whole different job! Oh and the particles for his fire breath!! And we havn't even done sound yet! We need a roar sound, a sound when he takes damage, when he attacks, and when he dies. Oh and don't forget about music...he might need his own theme song.

Now imagine that we want 8 different dragons. Each one a different element. The programmer would just take the old dragon coding and tweak it a bit. But the asset makers might have to start over from scratch depending on how different each dragon looks.

With how easy it is to make programs with advanced Engines like UE4 there is a reason that games are 2/3rs asset makers, our game will probably be 80-90% asset makers once we get started.

THE ABILITY TO MAKE A GOOD GAME is in NO WAY LIMITED by the number of artists on the staff.

>Yes, you do need an artist or two, skilled ones, to produce the graphics to make LttP puzzles looking good. You

You know what would make Link the Past awesome? Better graphics. Imagine if the enemy soliders were not same shit different color. The green soldiers could be tall and lanky. The blue ones really fat and short and the red ones could be beef-cakes. For fuck sakes man, making every asset unique would be a damn good thing!

>>2487208
Geometry wars isn't "thinking outside the box" and it's not a very good game (yes I've played it, beat the DS version)

It's looks like fucking tempest and it's level design is less advanced than fucking Xevious (literally the first scrolling shmup)

>>2487221
>I could string togeather a blueprint in a day for a Monster that walks around, looks for the player, and than tries to attack him.
And it would not make a game, just one tiny mechanic, that needs to be balanced with a couple dozen other mechanics, brought to live by level design that honors pacing, difficulty and sense of accomplishment. It needs to be paired with a player motivation, that needs to be kept high. There's very little difference, artistically, between doing a normal drawing and providing game assets. Writing the routines for a game though, is where everything can go wrong, because that's what the player interacts with.

>it would take more than a week for the artists to make the damn guy
And yet it would be nothing more than grunt work, and nothing specific to games. They rig models all day long for CGI movies and simulations.

>That's a whole different job!
I wished it was, but sadly the artists think they're making games.

>Now imagine that we want 8 different dragons. Each one a different element.
Now imagine the door I show you, when you waste resources on unnecessary repetition.

>The programmer would just take the old dragon coding and tweak it a bit. But the asset makers might have to start over from scratch depending on how different each dragon looks.
Yeah, one of them is being efficient, to make the game work. The other is wasting resources.

>THE ABILITY TO MAKE A GOOD GAME is in NO WAY LIMITED by the number of artists on the staff.
The resources of a project are limited. Every cent spent on a pixel shuffler is a cent not spent on QA, pathfinding, branching scripting and general concept.

>>2487224
>Geometry wars isn't "thinking outside the box"
It's taking an approach that anon instantly rejected, and ran with it. That's something I can appreciate.

>it's not a very good game
Critics disagree with you on that. The games score very high.

>It's looks like fucking tempest
Intentionally. The focus is on the mechanics.

>it's level design is less advanced than fucking Xevious
The game has no levels. It has a playfield. All challenge comes from enemy movement and density. And that's where the challenge in developing such a game is. Get any of the movements wrong, misjudge the hitpoints, and you throw off the balance and butcher the experience for the player. That matters much more than the color or shape of the enemies (though in this case the colors are chosen deliberately for quick recognition)

>>2487229
>sadly the artists think they're making games.
They do though, without artists you are limited to rogue-likes and text adventure games.

Making a video game is a group effort.

>Now imagine the door I show you, when you waste resources on unnecessary repetition.

So having more than 1 enemy is now unnessary. Kid what if these 8 dragons we are making are the bosses in the game. What if they are the only fucking enemies in the game and it's literally Hero vs the 8 Elemental Dragons Gaiden.

The point is that a programmer will make the nuts and bolts that make an asset run FASTER than the asset makers will make the fucking asset. It makes sense to hire a ton of artists and very few programmers.

>Every cent spent on a pixel shuffler is a cent not spent on QA, pathfinding, branching scripting and general concept.

And how does the number of artists affect this. If you make meshes can you not also help beta-test the game? Do you think the guy who is literally making the assets for your hero's weapons shouldn't have input on exactly what type of weapons the hero has and what they do.

Your basic idea is lots of arists=games turn into COD which is a shitty fucking argument. If you look at the credits for any video game ever (including retro ones) there are more artists than designers and programmers. That was in the dark ages when super advanced programs like UE4 and Unity didn't do 80% of the 'hard' programming for you!

>>2487238
>The focus is on the mechanics.
And the mechanics are worst than Xevious. Everything you said, the movement, the hit points, all of that is in Xevious: The first fucking scrolling shmup ever made! It's not new, it's literally the bare minimum needed to be called a shmup.

Geometry wars would only be impressive to someone that has basically never played a shmup in their life.

>The games score very high.
Who the fuck cares what critics say. Arn't they the same group that gives a 10/10 to annual COD?

>>2487245
>Making a video game is a group effort.
If only the artists would understand that.

>So having more than 1 enemy is now unnessary
remodelling when a palette swap would do is a waste of resources. Nice strawman though. Burn it all up.

>The point is that a programmer will make the nuts and bolts that make an asset run FASTER than the asset makers will make the fucking asset
The point is that producing assets is extremely low gain, compared to other aspects and produces no gameplay whatsoever. Scaling back any of the other aspects to finance asset creation is bad game dev.

>And how does the number of artists affect this
payroll, and computers in use.

>If you make meshes can you not also help beta-test the game?
Usually not. Testing is a full time job.

>Do you think the guy who is literally making the assets for your hero's weapons shouldn't have input on exactly what type of weapons the hero has and what they do.
Yes. He's the brush version of a code monkey. The creative input is for the director.

>>2487247
>It's not new
I didn't claim it was. It was very well done and successful.

>it's literally the bare minimum needed to be called a shmup.
That's its beauty. It's the essence, and nothing more.

>It seems that perfection is attained, not when there is nothing more to add, but when there is nothing more to take away.
Antoine de Saint Exupéry

>Who the fuck cares what critics say
As a whole they tend to point out issues and positive aspects of games. My opinion isn't worth much, as I'm biased. Neither is yours. The opinion of a couple hundred anons though, especially when it converges on some point, holds some weight. Critics are a shorthand for that.

>>2487250
LOL at your sub-human philosophy. You can make a 'perfect' food by making flawless bread. But who the fuck wants to eat plain bread when you can have a sandwich, a pizza, or add 3 or 4 other items on the plate. Adding new stuff is the very basics of what it means to improve something.

If you honestly think that Geometry wars is anything more than mediocre you havn't played very many games like it. Single-screen shooters died out because scrolling shooters could have all the mechanics in addition to new ones being introduced as you scroll along (terrain to avoid, bombing sites like in Xevious). There is a reason no serious developers went on continue what was an inferior genre when they could make games like Gradius, R-type, Thunder Force, Raiden, DDP, Death Smiles, and hundreds more.

You also don't seem to get my analogy and are literally saying that a game which consists solely of 8 boss fights should not even have unique graphics for each boss.

>>2470724
For one you can share it around easily, and for two they save your game so you can play on a bud's system. Online accounts are NOT a good replacement.

I hope with SSD tech becoming cheaper we'll see them come back.

>>2487315
You do realize companys do not want you to share your games right? It makes them lose money.

Also the saving thing you mentioned already exists. Steam automatically uploads your accounts save files to a cloud and you can choose to use the cloud file, over-write it, or use a local file.

>>2487321
Yeah, using your Steam account on a buds system is a totally great idea. No one has has ever had their account cleaned out by a "friend".
You may as well just stop posting because you now have zero credibility.

>>2478774
So why does the CPU have DMA access to the ROM cartridge if it doesn't execute any code from it?

>>2470724
fucking retarded newfag threads
screw off

>>2488564
step 1. Log out of your friend's account
step 2. Log into yours
step 3. Download the file save from the cloud and play
step 4: Upload your new save to the cloud
step 5: Log gout

Unless your friend has a fucking keylogger you are fine

The lack of moving parts was pretty awesome in terms of durability for the console. Just look at the failure rates of cart based systems compared to disk based.

>>2488803
>The lack of moving parts was pretty awesome in terms of durability for the console.
Sure was.

>>2470724
They look way better on a shelf, they preserve better than discs, they're more satisfying to put into a system and they're capable of saving your game data on them. They're superior. They'll never come back, but they're superior to discs.

>>2488986
Not to mention (theoretically) faster load times. A modern, cartridge-based console would kick ass.

>>2489001
Just get more ram if you want faster loading.

>>2489001
>A modern, cartridge-based console would kick ass.
DS, 3DS

Nobody's going to make bulky carts anymore. I'm calling it now and saying Nintendo's next system will be digital only.

>>2470724
They were much faster, and had practically no load times as a result; they could save progress with a battery, removing the need for memory cards and the sort; and they could hold enhancers like the Super FX chip, making games the normal hardware couldn't normally handle possible without the need for add-ons *cough*32X*cough*.

>>2489009
PS Vita also uses cartridges.

>>2488778
>super convenient
>being this naive
Any other own goals you'd like to make?

>>2489006
RAM doesn't work like that. You'll get less frequent loading with more RAM. Not faster loading.

>>2489142
And because it's less frequent it goes faster.

>>2489468
loading a fixed amount of data from medium into RAM takes the same time, no matter if you got little RAM and do it in parts, or if you shove all of it at once into your bigger RAM.

>>2489473
Not having to re-load that data because you have more RAM means less to load. So it's faster.
Keep digging that hole aspie.

>>2489018
>removing the need for memory cards

WHY DO PEOPLE KEEP SAYING THIS?

>make a console that uses carts
>no loading
>bad ass graphics
>carts are expensive but people don't care
>make the console so fucked up that it's impossible to emulate
>????
>second coming of the carts

>>2490390
>make the console so fucked up that it's impossible to emulate
That's gonna be a lot of fun during game development

>second coming of the carts
The NDS family is alive and kicking

>>2490396
>The NDS family is alive and kicking
I meant carts not sd cards.

>>2490413
Hate to break it to you, but those aren't sd cards.
Anyway, what's the difference between them and carts?

>>2490424
They sure look like sd cards. If they're not then never mind.

I was thinking of carts like snes, neo geo etc. Carts that actually looks like game carts.

>>2490413
the form factor may resemble SD cards, but that's where it ends. Inside you find a ROM (or multiple ROM chips), often an EEPROM/Flash chip for save states, and occasionally even more sophisticated hardware, like the bluetooth receiver in the pokemon typing game cart.
The form factor is for human reasons only, so the carts can be handled reasonably well. In terms of storage and capability though, they could be even smaller.

>>2490435
These carts were largely empty. Their size and shape was determined by what was considered useful for storage and human handling back then. The SD card established itself as a modern form factor though.

>>2490442
There is no need for carts to be small other than handheld console carts.

>>2490516
There's no need for them to be big either. The more compact carts are easier to mass-storage and easier to carry around (play on a friend's system, social gaming is big)

>>2490523
I wouldn't consider genesis, nes, snes carts big. If you took game disc with you, you would put it in the case anyway.

Hello, my name is The Reason Nintendo Lost the Fifth Generation.

>>2490354
Becuase it's true? Many cart-based systems had no memory cards, and even the N64 didn't require a controller pak to save data in most games.

>>2490354
You're not one of those people who thinks every game used the controller pak, are you?

>>2488702
The N64's CPU cannot DMA the ROM cartridge. In fact, its CPU cannot even DMA main memory.

However, the GPU can indeed DMA the above things, but that puts limitations on what the CPU can do with that DMA. The GPU can still benefit though. Realistically, even the N64's boot ROM is programmed to copy the first 1MB from the cartridge and dump it into RDRAM.

The system is really not designed to be running code off the cartridge. Streaming assets from the cartridge directly to the GPU would be far too slow (it's a slow interface).

Streaming assets gradually to well managed RDRAM? Well that's a different story. But the PS1 can do that as well. In fact, extreme streaming from CD-ROM is exactly what was used with Crash Bandicoot. The developers pre-calculated polygon sorting and occlusion lists and pumped them gradually from the CD-ROM into memory, and handed the CPU that information as you walk along the stages, thereby sparing the system a lot of computation. Granted, this kind of stuff was a special case, you can only do it with linear games.

Once again, the biggest advantage of N64 cartridges was no seek speed, not bandwidth.

>>2491420

>>2491420
Most of the leads on the board coming from the Cartridge run directly to the processor.

>>2491581
>>2491420
>Direct memory access (DMA) is a feature of computerized systems that allows certain hardware subsystems to access main system memory independently of the central processing unit (CPU).
Notice especially the last part.
The very purpose of DMA is to batch-load data from one memory region to another, without burdening the CPU. So it's usually done to load code or data into RAM.
The cartridge is memory-mapped, as far as I understand, so the CPU can treat it, memory-wise, as if it was RAM. There is, however, a latency when accessing the cartridge, that's much higher than RAM. Memory mapping does not mean RAM speed. So for speed critical things (that includes some code), it's first moved from one place in memory (cartridge) to another place in memory (RAM), before actually being executed. That moving is done via DMA, where the processor just says "I need all this data in that location" and then lets the dedicated DMA controller do its job, while it itself focuses again on making the game work.
All of this is done through the coprocessor and cartridge connector. The red circled section is an interrupt input, not a data line. I suppose it allows for cartridge-side hardware to trigger interrupts or otherwise "take control"

>>2491626
The diagram suggests that the cartridge is connected via connector, which has a serial and a parallel interface. The serial interface seems to have a few control and interrupt lines, and the bulk of the data moves through these interfaces and RAM. It makes sense, since memory mapping basically means that the CPU dials an address and receives data. Something needs to combine cartridge, RAM and possible VRAM into this one memory space and do all necessary translations

>>2491626
No, they really don't. The central chip is the GPU, the one of the left is the CPU.

I've also got a little bit of data for you guys.

The speed of the Parallel Interface (the DMA engine connected to the ROM cartridge) is 50MB/s (peak). Realistically, it's going to be 5MB/s, because that's about as fast the slow ROMs that Nintendo put into these cartridges go.

>>2491672
please give us RAM throughput for comparison as well, just so we get a more complete picture

>>2491672
>Realistically, it's going to be 5MB/s
It should be mentioned, for the sake of the topic, that throughput on the Playstation double speed discs at the time was a theoretical 300kB/s, just so we get the massive difference here. The cheap and slow ROMs Nintendo used were at least an order of magnitude faster than Sony's CD-ROM drive under perfect conditions. That's not accounting for latency in random access situations

>>2491679
RDRAM is 562.5 MB/s (peak). The latency is about 640ns (really high), so real bandwidth is going to be quite a bit less than the peak (but performance will be highly variable depending on the type of code - anything that uses random accesses will be very far from the peak, anything that linearly reads down the memory map will be quite close to the peak).

>>2491689
interestingly that also means worst case conditions for the RDRAM are probably quite close to ideal conditions on the ROM (which are unattainable, but bear with me). I'm saying this because usually there's a huge difference between RAM and persistent memory, multiple orders of magnitude. The smaller that difference is though, the less you need to rely on elaborate streaming and caching mechanisms. While there's still plenty reason to stream and DMA and stuff on the N64, the pressure is probably a bit less than what was needed to make a 2x CD-ROM perform reasonably.

>>2491684
>That's not accounting for latency in random access situations
Yes, indeed. On CD you have plenty of room to clone your data throughout the disk to help reduce any random reads.

BTW there's a possibly that the 50MB/s and 5MB/s figures I gave are actually in megabits. I can't remember.

>>2491718
(cont)
Also just as a follow up note, that 562.5 MB/s for the RAM (this one definitely megabytes, not megabits) is actually in 9bit memory. In 8bit memory it's 500MB/s.

CDs are perfect for sustained (not exceptionally fast, but consistent) sequential read, like, playing back audio, or even video. They're really terrible for random access reads, like, playing a video game. You can offset the drawback a little by increasing RAM (still need at least one slow sequential read to move it all into RAM), but that costs, which means it's not an option for consoles. It's the same with the DVD and BD. Perfect for smooth sequential reads and playback, really bad for random access.

On systems with a harddisk they worked around it, by doing one full sequential read (install), then taking advantage of the comparably better random access capabilities of the harddisk. That, however, means the disc is little more than a delivery mechanism, just like downloads would be.

A cart, meanwhile, is not a delivery mechanism, it's the actual and final data holder. Removing it from the system means removing the data from the system. So, unlike a harddisk, it can not ever "become full", unlike a disc it can be used during actual interaction and needs no preprocessing like an install, or awkward streaming solutions to work around the way the disc is accessed.

>>2491758
Due to carts holding the data it also means they are virtually impossible to patch or update. Modern developers kind of rely on that ability though, using customers as large scale bug testing.

>>2491672
That's central chip is the coprocessor. It has two seperate components and is not relegated to specifically GPU tasks. This is where the RSP DMEM is that I stated before that executes the boot code directly off the cartridge via DMA. That is the main game code. The infinite loop that runs (aka the game) until it's turned off.

As you can see from the picture, the vast majority of the leads from the cartridge go directly to the coprocessor thanks to the DMA controller on chip.

It's really hard to say they don't when you can physically see that they do.

>>2491635
That's why the DMA controller is located in the coprocessor and not on the CPU.

>>2492736
DMA controllers are not part of the CPU, by definition (SoCs don't count), I figured as much. Thanks for the additional info though that it's part of the coprocessor. I was somewhat wondering if it's dedicated, or if something else is doing it. Actually, it IS a dedicated component within the coprocessor die, that operates without bothering the other functions of the coprocessor, right?

>>2470779
This isn't really an advantage it just makes the game way more expensive.

>>2492746

Star Fox would not have been possible otherwise.

>>2492746
Might want to tell that Kirby Tilt'n'Tumble, Boktai or Pokemon Typing, to name just a few. All handheld carts, but still.

>>2492748
I know I'm in the minority, but I consider Star Fox a really bad example. The system was not designed for polygon rasterizing, at all. The SuperFX chip turns the whole thing upside down, reducing the SNES itself to a dumb pixel pusher that just passes on what the cartridge tells it to. It's like making a car fly by attaching wings to it, and claiming it's a plane now. The SNES has a really nice tile based engine, very versatile, plenty of power. It's a really awful and mediocre rasterizer, unable to access individual pixels, which is kind of a requirement for polygonal 3D.
The chip didn't enhance what the SNES could do, it bypassed everything it could do.

>>2492759
star fox was really dope tho

>>2492759

That's fine to say, you backed it up well. Try Yoshi's Island then.