Jump to content
IGNORED

On the importance of feel


Ransom

Recommended Posts

There are a lot of factors that go into a good gaming experience. Game design is obviously a primary factor. Sound and graphics matter. And, at least for classics collectors, so does feel.

 

If you're like me, the enjoyment you get from playing a game when using your favorite controller is vastly better than you get from playing the same game using a keyboard. And what Atari 8-bit enthusiast doesn't prize the slightly cool feel of the early, metal carts? Or 2600 fan the way the toggles feel when they slip into place?

 

This was all brought home to me the other night. I got a second-hand Atari 5200 trak-ball working and enjoyed a few rounds of Centipede. What a difference! Suddenly, a game I'd grown bored with decades ago was fun again. Why? At least partly, it was because for this game, the feel of rolling that sphere is so superior to that of pushing a joystick. Centipede was intended to be played with a trak-ball, and suffers when other controllers are used.

 

The same goes for all the classics. Sure, I can play any video game ever made using nothing more than my computer. The keyboard and a mouse will emulate any control scheme ever invented (albeit with varying degrees of success). But those who have tried it know -- it's never the same that way. It's always an inferior experience. And it always will be.

 

Oh, but you can hook up real controllers to your computer! That will solve it, won't it?

 

No, not for me. Because it's not just the controllers. It's also the switches. And being in front of a TV. And putting a cartridge in the slot. And a million other little enjoyments you get when you sit down to play a console game on its original hardware.

 

That gets to the heart of the matter for me. Not only are proper controls necessary to the full enjoyment of a game. They also have to be played on the real hardware for which they were designed. As Mirage1972 recently pointed out, that's the only real way to tell if you like a game.

 

I would add: that's the only real way to play a game.

 

Anything else, and you're just playing an echo.

Link to comment
Share on other sites

You sum things up quite well. I could easily play my Atari library on the computer, but where would the fun be? I can't manipulate the switches, I don't plug in the cartridge...what the Genesis? Some of my most vivid memories of video gaming involve sitting in front of the TV in my parent's kitchen and playing for hours. You definitely miss a lot of the experience when playing on different hardware.

Link to comment
Share on other sites

++ -- obviously :)

 

As for playing on real hardware vs emulation, it's not only all the points you mentioned, but also the way it appears on-screen. The Atari 8-bit computers and 5200 moreso than other machines from what I've experienced. Something about the way they display graphics. I wish I could explain that in technical terms, but I can't. In emulation, it's just not the same, and like you did say, it's even better on a TV (even if that's just because it's the way most of us remember console games).

 

And I shed a little tear when you mentioned the Trak-Ball. Mine died (optical sensors apparently) and I need a new one. Haven't had time to put much effort into it yet this week. That thing makes the system -- best Trak-Ball for any console ever.

Edited by Mirage1972
Link to comment
Share on other sites

Word!

 

I am an advocate of playing games on the original hardware too. I have emuators, I even use them from time to time... they just aren't the same. The experience might improve with a USB controller, but there is still a void left there. About the only thing I emulate on a regular basis is arcade stuff, and the reason for that is pretty obvious.

Link to comment
Share on other sites

I feel precisely the same way. I've stated many times before concerning my preference of utilizing the original controllers with their associated systems. This is also inclusive to the feel of certain versions of keyboards to the various vintage computers I have. I've noticed that there's certain keyboards to the Commodore 64's that feel......"mushy" and some that have a precise snap to them. And not just the feel but the sound as well. In fact when I type in a load sequence such as Load "*",8,1 it sounds, to me anyways, like the sound the keyboard did in the original Alien movie when a crew member was communicating with Mother in that all while room with the blinking clear lights. Likewise I much prefer the look and feel of the original Atari 800 to the XL model. It's also the odd layout of the keys, whether it be a TI99/4A, Apple ][e, CoCo3 or even the less than perfect rubber keys of a Mattel Aquarius or Tommy Tutor. That goes as well with the feel of handling the old 5 1/4 floppies and the tactile stimulus of operating the latch of a FDD on a P.E.B or Apple ][ unit or the unique sound of a 1541. People love to complain about the controllers for the 5200, INTV and the CV but there's nothing that compares to the way they feel and how a game is played while using them. Personally, I wouldn't have it any other way.

Link to comment
Share on other sites

I'm one of the people who wanted one of those things where you could put a bunch of cartridges in it and press a button to select an Atari 2600 game.

 

post-13-1236870366.jpg

 

Never cared for the old in-out, in-out when it came to Atari cartridges. Never cared much for sliding switches back and forth either. I just wanted to play the games and I can't wait until there is no difference between emulation and the real thing.

 

I still don't understand why a virtual version of an Atari 2600 can't exist on the computer. It would be an exact copy of the guts of an Atari 2600, but a software version of it. It would act and sound exactly like a real Atari 2600 because it would virtually be an Atari 2600.

Link to comment
Share on other sites

I still don't understand why a virtual version of an Atari 2600 can't exist on the computer. It would be an exact copy of the guts of an Atari 2600, but a software version of it. It would act and sound exactly like a real Atari 2600 because it would virtually be an Atari 2600.

What you are describing is the very definition of an emulator. As we've all seen, emulation is seldom 100% perfect.

 

I'm more interested in going in the other direction... with all the technology we have at our disposal, why can't we have a hardware clone of a 2600/NES/whatever that's 100% accurate? Why are they all just *slightly* off, if not more?

 

I've also wondered what it would take to make a hardware PC emulator... create an actual slot on the PC to accept the cart, clone hardware in the drive performs the actual work, and PC software outputs the audio and video.

Link to comment
Share on other sites

I'm totally with Ransom here.

Emulators are a VERY poor subsitute for the real console. I use Stella to look at a game to see if i want the real cart and nothing more.

The Odyssey2 and Vectrex are 2 systems i really feel give you nothing under emulation as well, the whole feel is just not there.

Even down to opening the box and feeling the cart in your hand, having something solid is important to me, I don't use itunes for the same reason.

there is no substiture for the real thing as far as classic games are concerned.

Link to comment
Share on other sites

What you are describing is the very definition of an emulator. As we've all seen, emulation is seldom 100% perfect.

I thought an emulator was a programmer's attempt to get games working as closely as possible, but what they made really wasn't an exact virtual duplicate of the guts? Isn't it different from a 3D virtual reality copy of an Atari 2600 that simulated electricity runs through? The only difference between the Atari 2600 on the computer screen and a real Atari 2600 would be that you couldn't touch the one in the screen. Is virtual reality advanced enough to simulate enough of the real world to do that yet?

Link to comment
Share on other sites

What you are describing is the very definition of an emulator. As we've all seen, emulation is seldom 100% perfect.

I thought an emulator was a programmer's attempt to get games working as closely as possible, but what they made really wasn't an exact virtual duplicate of the guts? Isn't it different from a 3D virtual reality copy of an Atari 2600 that simulated electricity runs through? The only difference between the Atari 2600 on the computer screen and a real Atari 2600 would be that you couldn't touch the one in the screen. Is virtual reality advanced enough to simulate enough of the real world to do that yet?

 

 

weirdly I have the intellivision 10-1 Plug and play effort and the emulation/simulation is apparently really poor but I still like shark! shark! on it as much as i did playing on my mates real hardware back in the eighties plus it only cost £2. Maybe the controller and TV combo. I guess we all grew up playing games on the old Cathode ray tube!

Link to comment
Share on other sites

What you are describing is the very definition of an emulator. As we've all seen, emulation is seldom 100% perfect.

I thought an emulator was a programmer's attempt to get games working as closely as possible, but what they made really wasn't an exact virtual duplicate of the guts? Isn't it different from a 3D virtual reality copy of an Atari 2600 that simulated electricity runs through? The only difference between the Atari 2600 on the computer screen and a real Atari 2600 would be that you couldn't touch the one in the screen. Is virtual reality advanced enough to simulate enough of the real world to do that yet?

 

Perhaps we're getting into a difference of semantics, but an emulator is an attempt to get one device to match the input and output of another device... or as a lot of people say "make your computer think it's an Atari". A program like Stella takes the binary ROM and translates the instruction set (assembly) into a program that runs on Windows/Mac/*nix. In order to do this, the designer of the emulator needs to know what the original hardware would have done with the instruction, and how to translate that into C++/VB/etc.

 

If this is different than what you're describing, I'm not seeing it.

Link to comment
Share on other sites

. . . the designer of the emulator needs to know what the original hardware would have done with the instruction, and how to translate that into C++/VB/etc.

That seems to be the difference right there. The designer of the emulator is interpreting what he thinks the real hardware will do, but if there isn't a way yet, I hope there will be soon where there is no knowing what the original hardware will do, an actual working version of an Atari 2600 will exist in virtual reality. It will be a complete, highly detailed 3D model, but model is the wrong word. It would be more than a model. The 3D 'model' will have working parts inside that act no differently than the parts inside of an Atari 2600 out in the real world. There would be no guesswork or workarounds or unexpected bugs. The virtual reality world that the virtual Atari 2600 is sitting in would give you more than any emulator can. You'd have a real Atari 2600 in your computer.

Link to comment
Share on other sites

. . . the designer of the emulator needs to know what the original hardware would have done with the instruction, and how to translate that into C++/VB/etc.

That seems to be the difference right there. The designer of the emulator is interpreting what he thinks the real hardware will do, but if there isn't a way yet, I hope there will be soon where there is no knowing what the original hardware will do, an actual working version of an Atari 2600 will exist in virtual reality.

 

I think I see what you're saying, though the end I'd say what you'd have would be an emulator, albeit a very accurate one. I don't know enough about low-level programming to speculate about how feasible this kind of a project would be, but I know even the best attempts at this have their flaws.

Link to comment
Share on other sites

. . . the designer of the emulator needs to know what the original hardware would have done with the instruction, and how to translate that into C++/VB/etc.

That seems to be the difference right there. The designer of the emulator is interpreting what he thinks the real hardware will do, but if there isn't a way yet, I hope there will be soon where there is no knowing what the original hardware will do, an actual working version of an Atari 2600 will exist in virtual reality.

 

I think I see what you're saying, though the end I'd say what you'd have would be an emulator, albeit a very accurate one. I don't know enough about low-level programming to speculate about how feasible this kind of a project would be, but I know even the best attempts at this have their flaws.

The problem is, all the current emulators for the 2600 emulate the system at what I call the 'black-box' level. That is, you put a certain input on certain virtual 'pins', and observe the output on a real system. Then, you write code that emulates that behaviour. The problem with that approach is that essentially, there are 'bugs' in the real circuits in a real system, and all the behaviour isn't yet fully known or understood.

 

In my recent work with upgrading the TIA support in Stella, it has brought the emulation closer to the real thing. For this, I've borrowed ideas from z26, MESS, and EMU7800. But all these emulators, including Stella, are still just emulating what we see on a real system. Something that hasn't been seen yet obviously won't be properly emulated.

 

There was some talk of adding code to Stella to emulate the TIA at the gate level. That is, the entire TIA class would basically be interactions of the most basic gates used in the real system (probably down to the AND, OR, NAND, NOR level). If done correctly, this would emulate the real system at 100% accuracy, even for things that have never been observed yet on a real system (ie, you could use the emulator to determine new 'tricks' which have never before been seen on hardware). This approach was never realized since we don't have the time and manpower, and for me personally, the background in electrical engineering necessary to do it. But if was ever done, it would be the definitive emulation of the TIA chip. I don't see it happening anytime soon ...

Link to comment
Share on other sites

There was some talk of adding code to Stella to emulate the TIA at the gate level. That is, the entire TIA class would basically be interactions of the most basic gates used in the real system (probably down to the AND, OR, NAND, NOR level). If done correctly, this would emulate the real system at 100% accuracy, even for things that have never been observed yet on a real system (ie, you could use the emulator to determine new 'tricks' which have never before been seen on hardware).

I've always wondered why emulators didn't work that way. Guess I'm not the only one.

 

but I think there will always be more layers of garbage between the joystick in ones hand and movement on the screen with software emulation vs real hardware, so especially on the older systems (16-bit and earlier) I wonder if they'll always be just a little bit off. Between the extra hops input takes on a cpu motherboard, and going through the OS's hoops before it even hits the emulator. No idea how measurable such a thing would even be though.

Edited by Reaperman
Link to comment
Share on other sites

There was some talk of adding code to Stella to emulate the TIA at the gate level. That is, the entire TIA class would basically be interactions of the most basic gates used in the real system (probably down to the AND, OR, NAND, NOR level). If done correctly, this would emulate the real system at 100% accuracy, even for things that have never been observed yet on a real system (ie, you could use the emulator to determine new 'tricks' which have never before been seen on hardware).

I've always wondered why emulators didn't work that way. Guess I'm not the only one.

 

but I think there will always be more layers of garbage between the joystick in ones hand and movement on the screen with software emulation vs real hardware, so especially on the older systems (16-bit and earlier) I wonder if they'll always be just a little bit off. Between the extra hops input takes on a cpu motherboard, and going through the OS's hoops before it even hits the emulator. No idea how measurable such a thing would even be though.

This latter part is something I've put a quite a lot of thought into. Of course, there's always going to me more layers when emulation is involved, but as long as the host system is fast enough, you'll never notice it. An NTSC games runs at roughly 60Hz. This translates into 16.66667 milliseconds for each frame to be processed. The host computer must be able to read all inputs from the user, process them as a real system would, and spit out a framebuffer image (as well as blit it to the screen). If all this can be done in 1/60 of a second, then the number of layers in between is irrelevant.

 

Much more important is when it all happens. All current popular operating systems are not real time. That is, they cannot guarantee when something will be done. So in Stella, assuming a frame takes 3ms to complete, the emulator must wait another 13.6666667 ms before starting the next one. More importantly the delay between each frame being displayed must be exactly 1/60 of a second. No operating system can guarantee this, so the result is 'jumping' in the onscreen image, where the game doesn't appear smooth. But If we can sync to an external timer that is very accurate, then smoothness can be achieved. That's why I like OpenGL mode in Stella on LCD hardware so much; the emulation can be sync'ed to the refresh rate of the monitor (60Hz), and emulation becomes extremely smooth.

 

And you don't necessarily need a fast system to do it, or even OpenGL, really. The GP2X is a 200MHz system which only supports software mode, and it keeps the emulation smooth exactly because the updates are sync'ed to the screen refresh rate.

 

Long story short; speed-wise, we've long since passed the limit where 2600 can be emulated correctly. The remaining problems are (a) perfecting the emulation of 'bugs' in the original hardware, and (b) having a sufficiently fine timer on the host system to sync to. Part (a) I'm working on. Part (b) Is more of an issue, and is likely out of my control.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...