potatohead's Blog

Both paddles and driving controllers need to be read as part of the kernel, and I don't know how much flexibility BB gives you in that area. But I do agree that there are certain classes of games where a paddle or spinner is superior to a joystick because you aren't limitted to a single speed.

 

Sure X is nice, but it often doesn't play nice with the native windowing system. It's also heavy on the network; so much so that I will VNC into a local system instead of running the X-Server on my PC. (And that's the exception, 99% of the time I stick to SSH shells.) Window Managers, fonts, focus handling, and window controls can also cause headaches.

 

Multi-user is good, but tough to get right from a security perspective unless you're really hard-nosed and dilligent. You also have to prevent users and rogue processes from gobbling up the CPU, RAM, and disk space impacting the other users & processes.

Both paddles and driving controllers need to be read as part of the kernel, and I don't know how much flexibility BB gives you in that area. But I do agree that there are certain classes of games where a paddle or spinner is superior to a joystick because you aren't limitted to a single speed.

 

Sure X is nice, but it often doesn't play nice with the native windowing system. It's also heavy on the network; so much so that I will VNC into a local system instead of running the X-Server on my PC. (And that's the exception, 99% of the time I stick to SSH shells.) Window Managers, fonts, focus handling, and window controls can also cause headaches.

 

Multi-user is good, but tough to get right from a security perspective unless you're really hard-nosed and dilligent. You also have to prevent users and rogue processes from gobbling up the CPU, RAM, and disk space impacting the other users & processes.

 

My thought on the driving controller was to treat it as a joystick, and nestle the reads in the game logic code. There is enough time, I just don't know if there is enough consistancy. Should be entertaining to find out. At least with the driving controllers, small timing differences won't result in jitter when the player is not interacting with the controller. However, there might be jitter on motion as well as a general inability to read the device fast enough to track state changes. We shall see.

 

Native windowing systems are a problem, if they are other than X window ones! That's a big reason why I run Linux / IRIX as my main desktop. On win32 Exceed is just great and interacts nicely with win32 desktops, but it's pricey...

 

I've not had any real trouble with network traffic. Guess the networks I work on are fast enough. Low latency is important though. Agreed on focus issues. Having the background I do, the default win32 focus drives me nuts! Should be able to interact with a window without having it pop to the foreground... point to focus and click in border to raise is my favorite --particularly when doing admin with lots of shells. Ordinary users hate this however, so I use Exceed and the native win32 window manager. That way the focus behavior is what they expect. A font server is a must, once done it can be left on and running no worries there.

 

Managing processes is a nasty one sometimes... A lot of what I have done over the years involves a couple of high-end applications. Once their behavior is known, a few scripts to assist program start and exit do wonders.

 

It's a tradeoff to be sure. Given the current mess win32 makes, I'll take these problems any day of the week over registry coruption, dll conflicts, and virii / malware. Things in win32 land are nicer these days for sure. I do manage both and find myself thrashing in win32 land far more than I do Linux / Unix land. IMHO, it's easier to know exactly what the machine is doing in Unix land than it is under win32. Too many things lumped together and too difficult to limit what a user can and cannot do. For win32, the core permission set and management tools recently released are actually quite good. Problem is most developers have not taken the time to code their stuff in a way that makes sense given the needs of administrators today. It will catch up, but it's just not there yet...

 

On the matter of security I've got problems on both sides of the fence.... It's just tough today, no getting around it. I tend to have strong outer layer security, then different subnets internally depending on the user needs. This is one thing X is nice for. It is possible to have one box locked down tight, only allowing an application server to serve it's application on managed data. Users can't touch anything on it, except via X. For engineering CAD data, for example, this is just fantastic in that the same system can run for years without any real need to manage it's interactions with the rapidly changing client environment and it's potential contaminants. You give up some nice integration, but you get robustness and consistancy in return. Not a bad tradeoff, IMHO.

Both paddles and driving controllers need to be read as part of the kernel, and I don't know how much flexibility BB gives you in that area. But I do agree that there are certain classes of games where a paddle or spinner is superior to a joystick because you aren't limitted to a single speed.

The DC does not require kernel time. However, I have had some trouble reading it in bB - I could never get the assembly routines posted by Thomas to work, so I wrote my own rather inefficient (but 100% working) routine and posted it here:

http://www.atariage.com/forums/index.php?showtopic=87310

 

In other news, the bB kernel now has paddle support in exchange for Missile 1. I have been doing some bB kernel hacking lately, and in doing so I've been finding cycles where I never thought I would. The SBX instruction is proving to be indispensable.

 

For example, there have been requests for a kernel with no blank lines between playfield blocks. This is also now an option by removing missile 1. However, in doing so, I found free cycles, which was enough to read any of the four paddles, so I decided to make paddle reading a feature of the no-blank-lines kernel option. Well, it's not perfect, as the paddle is read only every other scanline, so on the horizontal axis this translates to roughly a 2-pixel resolution (but should be adequate for most games.) You can also read multiple paddles, but must do so on alternate frames.

 

The driving controller is worse for a game like Ooze, as the DC has just 16 positions. However, I posted a demo a while back showing how one can measure the angular velocity of the DC and move a variable number of pixels accordingly. The end result is workable, if a little choppy. It takes a while to get accustomed to the control, but once you are used to it, it can feel much like a paddle. Demo is here:

 

http://www.atariage.com/forums/index.php?a...e=post&id=41269

 

Note that the demo must be played on real hardware with a real DC. It will not work as expected in any sort of emulator, as these limit the DC to a fixed angular velocity.

Both paddles and driving controllers need to be read as part of the kernel, and I don't know how much flexibility BB gives you in that area. But I do agree that there are certain classes of games where a paddle or spinner is superior to a joystick because you aren't limitted to a single speed.

The DC does not require kernel time. However, I have had some trouble reading it in bB - I could never get the assembly routines posted by Thomas to work, so I wrote my own rather inefficient (but 100% working) routine and posted it here:

http://www.atariage.com/forums/index.php?showtopic=87310

 

In other news, the bB kernel now has paddle support in exchange for Missile 1. I have been doing some bB kernel hacking lately, and in doing so I've been finding cycles where I never thought I would. The SBX instruction is proving to be indispensable.

 

For example, there have been requests for a kernel with no blank lines between playfield blocks. This is also now an option by removing missile 1. However, in doing so, I found free cycles, which was enough to read any of the four paddles, so I decided to make paddle reading a feature of the no-blank-lines kernel option. Well, it's not perfect, as the paddle is read only every other scanline, so on the horizontal axis this translates to roughly a 2-pixel resolution (but should be adequate for most games.) You can also read multiple paddles, but must do so on alternate frames.

 

The driving controller is worse for a game like Ooze, as the DC has just 16 positions. However, I posted a demo a while back showing how one can measure the angular velocity of the DC and move a variable number of pixels accordingly. The end result is workable, if a little choppy. It takes a while to get accustomed to the control, but once you are used to it, it can feel much like a paddle. Demo is here:

 

http://www.atariage.com/forums/index.php?a...e=post&id=41269

 

Note that the demo must be played on real hardware with a real DC. It will not work as expected in any sort of emulator, as these limit the DC to a fixed angular velocity.

 

As usual, nice work Batari. I can't wait to begin toying with this stuff again. It's a ton of fun compared to the nasty systems I deal with daily...

 

Many thanks (I think) for creating such a wonderful timesink!