Jump to content

Oppressor

Members
  • Posts

    24
  • Joined

  • Last visited

Everything posted by Oppressor

  1. Dude, we're on a forum where people still argue about 2600 Pac-Man. OK, I didn't know your life was that empty. I so hope that Fake Dr. Smart fills your existence with purpose again someday. Scott, that whooshing sound was you competely missing my point that practically the sole purpose of this site to talk about old games... most of them being much, much older than BattleSphere. If you want people to talk about something newer, start work on a new space combat game. They seem to be all the rage in the indie game dev scene these days. OMG No wonder you guys hate TBird and Gorf so much! All that racket they raise about new jaguar games and technology puts the pooper on your panty bunching poutfests about the past. Thanks for straightening me out on that one! Here, I'll even make friendly: That Club Drive sure is teh suck!
  2. Dude, we're on a forum where people still argue about 2600 Pac-Man. OK, I didn't know your life was that empty. I so hope that Fake Dr. Smart fills your existence with purpose again someday.
  3. As it turned out, the game of "Looking Forward to Battlesphere" turned out to be more fun than the game itself. I respect the hell out of the technical achievements of BS, but there are just so many questionable design decisions -- from the democoder aesthetic to the largely-useless netplay -- that my enthusiasm for the game dropped to nil within a few hours of finally plugging in that first-run cartridge. Plus, in the years leading up to BS's release I got quite addicted to Freespace, which flattens BS in almost every conceivable way (an unfair comparison, I know, but nonetheless). But come on, I've always been a cranky ass. Well... I get that, but I still don't get why you yammer on about it - nearly a decade later... Let go, move on, and put your hopes and expectations into Derek Smart's Freespace 3, mmkay? I promise he'll give you something with many many many more questionable design decisions! Why you could probably spend the rest of your mortal life on that one.
  4. Nobody with a clue thinks Doug was the sole author of BS. Damn right! Ergo it seems like there are a lot of clueless souls hanging out here. Ya know Clay, I have no idea what happened to you. I do know we used to get along, hell you wrote the game's FAQ, but your OCD on some minor issues over the HUD and the menus of the game is ridiculous. I'll assume you've just decided to devote your life to getting Doug's goat, but having known the guy for almost 30 years, that is a fool's errand - something many on here could stand to learn. It's not like anyone who has developed anything complex for this platform is among the bashers. Quite the opposite actually: do something technical for this community and one will immediately become a target. As for the game itself, I'll stick to what the major media has repeatedly said about it, which in some ways is a shame, as I am a big fan of constructive criticism. I can only guess that some form of latent fanboy autism has sprung up in your psyche and therefore any deviation from the original Star Raiders is unforgivable heresy. So um, why didn't you just jump the fence back in the 90s and save us all a lot of time?
  5. Umm, are you not banned from this site? Yeah, it's a funny thing, but Doug wasn't the only author of BattleSphere. It's not like anyone bothers to keep track though. But given how badly some of the 'tards on here have mangled the history of the project, I'm not at all surprised. Hey Al, once again feel free to delete this account with my blessing. I'd do it myself if I knew how in fact. Anyone with mod powers watching this thing? 'Nuff said.
  6. In no particular order: ZB: Who killed your puppy? Seriously. I mean I love constructive criticism and if I had to do it again, we'd make the capital ships segmented like SS, and add a distance indicator, but man, you must have eaten some Death's Angel mushrooms in the year 2000 or so. Sorry to hear it. You used to be a fun guy. SL: Never, ever. And our preservation plan is far beyond anything your tiny mind could conceive so just go to EBay and pay $500+ for it already, mmkay? You guys created the situation, not us, so go wallow in it with the rest of the, um, hobbyists. BB: Thanks for the laughs. I was beginning to miss Sinflop and all that. Go Team Brasky Go! And well, at this point, this long dormant account will probably get deleted for not properly goosestepping and all that so arrive derci if I'm not heard from again...
  7. I think BattleSphere Gold has that nitpick addressed wherein you can switch the enemy target colors. I don't know - that project was mostly Doug's work with only peripheral involvement from me. I've been on the next thing for several years now in my fleeting free time. As for why that color scheme? Read _Bill The Galactic Hero_ by Harry Harrison for a thorough discussion of the subject. I'll stand by the assessment that I think it's a better color scheme, but since nearly every other game in the universe does it the other way around, I acknowledge the mistake. And the next thing is a new version of the game described partially in a 50 or so page spec. X2: The Threat managed to scoop us slightly with multimonitor support (and good for them BTW), but there's still plenty of never-before-seen goodness to be implemented. It will be done when it's done. In this case, the longer it takes, the better it will look since I'm a big fan of Moore's and Pixel's Law. No funding whatsoever once again - there's no way the industry would pay a bunch of unknowns to attempt what we're attempting and we prefer to rule in Hell anyway. Besides, while it's annoying to still have zero credibility with the game suits, we have beaucoup cred in the tech industry now and that really helps pay the bills.
  8. You're joking, right? Good access? BWAHAHAHAHAHAHAHA... Ow that hurts... All we had was the Jaguar Developer's Manual and access to the BBS on which little of use was posted except for occasional and randomly buggy updates of RDBJAG. Our relationship with Atari at that time was at best, strained. They saw us as lunatic unfunded fanboys who would never finish their title, and we saw them as roadblocks because they wouldn't spill the beans on issues like the UART bug in a timely manner. We were on a holy quest. That's what people both loved and hated about us. I know there's been some fascinating speculation about our amazing relationship with Atari, and these days, I'm on great terms with a lot of former Atari employees, but at the time, we were utter outsiders who did this entirely in our spare-time and bought our own equipment. And no funding whatsoever. We're really good coders who didn't know when to quit, deal with it, OK? Meanwhile, when we went on the road and tried to get funding for a future edition, we were rewarded by some venture-funded asshats in Santa Monica, CA who tried to steal the title and concept shortly after Atari's death, assuming we died with them (strange but true). Never mind my apartment was two miles from their offices, and they could have just funded us instead and actually obtained a finished product, but I digress... My advice: do what feels right in your game. If gamers tell you it sucks, listen to 'em. Easy to elaborate, difficult to follow, apparently, for many.
  9. Basically, I looked at Quake, which was a mega-hit, selling far more copies than there are jaguars, and aped a lot of their interface. One should always steal from the best... Foolish pride is the enemy of quality... OTOH false humility is pretty useless too... Ironically, Quake 3 has a weapons HUD nearly identical to that of BattleSphere. I'm not saying they copied it from us, but merely that great minds think alike... To this day, I continue to steal/copy/improvise on other people's ideas. What's the point in ignoring the self-evident progress of others? If you can explain that to me, I think I'd understand European space shooters like X2: The Threat a lot better...
  10. Actually, we followed the spec better than most Atari games in that our networking actually worked, but don't let our superior engineering skills get in the way of a good opportunity to take a shot at Doug where he can't fire back...
  11. Cherokeecrow sounds about as much like Thunderbird to me as Gunstar sounds like anal cyst. Now if what you're trying to say by starting yet another thread attacking Doug in a place where he can't defend himself is that you are indeed an anal cyst, well I'm in complete agreement with you. Or is it that you miss the guy and desperately need an adversary to fill your otherwise empty moments? In that case, might I suggest some of the many fine other jaguar developers who are still in the community and therefore can be driven away victoriously, leaving you the king of nothing? Doug is not hijacking your auction, I am not hijacking your auction. In fact, we have no idea WHO is hijacking your auction. Why don't you go through EBay's complaint department and let them do your dirty work instead of kneejerking accusations? Otherwise, you'll just end up eating crow yet again. Hey Albert, time to lock another thread, isn't it? And of course, it's probably also time to ban me because I just defended the antichrist, right? Cheerio!
  12. Having gone beyond the rim a long time ago, I figure I'd return just in time to get kicked out of here There's a valid complaint here that Doug was the center of many teapot tempests on this bulletin board, and on those grounds, one could make an argument that he had to go for the sake of world peace/taking one for the team.. But as for what he gave the Atari Jaguar community - 8+ years of creative energy, a good fraction of his disposable income, and multiple topnotch products whose production standards have yet to be met by any other homebrew operation. Were we responsible for making the Jaguar an open platform? Yes and no. Yes, we were the lightning rod through which the energy of many was channeled up the digestive back-end of Hasbro until they relented, but there were some unexpected and unnameable heroes involved in that effort. The full story is unlikely to ever be revealed. But back on topic, most prominent game developers have stopped associating with the public except under tightly controlled circumstances. There's a reason for that: It's some sort of silly testosterone problem where everyone wants to gun down the successful. Short of sex change operations for obnoxious posturing fanboys, the only solution to this dilemma is to disappear, and so that's what most developers do. This past week's theft and distribution of the Half Life 2 source code brilliantly shows what the successful can expect to happen to them. Albert, in closing, I gotta say, IMO you're a jerk who seems to really want a one-sided T-Bird bashing forum after insisting you wanted these threads to stop. Please ban me, for I'm a bad man too. And yo, remove the scans. They are copyrighted material after all. Thank you. Your board and all, our game. I'm sure you understand. "If you pick up a starving dog and make him prosperous, he will not bite you. This is the principal difference between a dog and a man." - Mark Twain
  13. No, all it needs to do is monitor whenever there's a write to B_CMD and then extract the current values of the input registers, which is what software emulation is doing already. It's what would be done next that would be different. And it would end up faster, not slower than software emulation since the blitter would now run for free, rendering entire triangles as opposed to single scanlines. But I actually agree that software emulation should be finished first. And most people are too cheap to upgrade their video cards to something remotely current anyway. So even though they'll need a 2-3 GHz CPU to run this emulator effectively, I'm 95% certain they'll hobble it with a 5 year old video card because $120 is $120 too much I say! Besides, you think an emulator author is going to share source code and/or provide an interface for someone else to add to the thing? BWAHAHAHAHAHA. As for owning the real thing, of course that's better, but sheesh, in the long-term, all of our jags are going to die, and I'd like to make sure BattleSphere can be played decads into the future for anyone crazy enough to still want to play it. I won't be writing this anytime soon though, mark my words.
  14. So while we're on the topic, here's an immediate optimization to recover actual triangles (and even textures) from single scanline blitter commands. When you issue the first blitter command, save the left and right starting positions. Do the same when you issue the last blitter command. Every time the increment from one scanline to the next changes in magnitude, sign, or both, save that vertex too. Voila, you've just recovered an intact polygon from a bunch of individual commands. Now triangulate the sucker and send it to the 3D hardware of your choice (there are some minor complications that could arise here, but get 99% of the polygons working before worrying about this). If you're texture mapping, note the source pointer to the texture in memory, and its width, and round its height off to the nearest power of 2 that contains all the texture coordinates of the vertices you just collected. Now create a texture and fill it with all that data: converting it to RGB while you're at it. Now hash that texture's source pointer and width, save the height, and now you can recognize it quickly on the next and all subsequent frames. The only trick now is to make sure those textures stay current by setting page faults whenever their memory range is touched in order to alert one to refresh that texture from jaguar memory the next time it's used. If you're not texture mapping, well then just grab the CRY colors from the vertices and convert them directly to RGB and off ya go. Isn't it fun to mess with the mind of old code and hardware? Now I'm utterly convinced this puppy would fly... And if there's someone out there with no life on par with the guys who wrote ASCIIQuake, here's the megabonus round. Take all those textures just pulled dynamically out of the jaguar game as ti ran and write them to files. Now go into photoshop and crank up their resolutions to whatever you like. Now put hooks into the emulator to automatically replace the original textures with these "improved" textures. It'll be even better than Combat Rock I tell you.
  15. P L A C E B O E S... Man!!!! And you should know, you're the one that sent them to me...
  16. Did you actually understand a word I typed? I coded the jag for 6 years: I frickin' co-wrote BattleSphere with Doug (and specifically wrote the polygon engine): I know how the damned thing works better than anyone short of another jaguar developer or an emulator author. I think I know how well the aforementioned approach would work. And what the heck are you raising infinite planes for? Technobabble -20, nice try though, did someone give you a free PowerVR T-shirt or something?. Go back and read some more: I'm talking about mapping blitter commands and video memory accesses directly down to polygon commands: the bottom line is that one-way write access would be easy, reading back the framebuffer would be the tough part unless it was done with the blitter itself at which point it could all be pipelined through Direct3D or OpenGL (check out Game Programming Gems I for just such an approach to lens flares in Direct3D). Since the task I took upon myself after BattleSphere was writing an OpenGL for Nuon, I suspect I know a great deal more about both the jaguar and 3D APIs than you do. But I can already think of one case that would trip this up: using GPU RAM as a blitter cache. But even that's not so tough to get around: just copy the source memory off somewhere else (again, into a source texture) and set up a series of blitter commands off of the copied (rather than the original) memory. Slow? Nah, Pentium 4s and Athlons perform straight line copies at terrifying speeds. And this is all pretty basic 3D driver engineering (which is what I do for a living now only they call this concept "renaming" in the DirectX docs, see D3DLOCK_DISCARD), OK? If anyone had ever released a HAM mode video game, that would have been trouble as well. Fortunately, I think only Kris Bailey at H2O even knew that could be done with the object processor and he found it was not all that more efficient than just using the blitter or the GPU As far as I know, all shipping polygon titles (CyberMorph, BattleMorph, SuperCross, Club Drive, I-War, Zero 5, Fight For Life, Missile Command 3D, BattleSphere, HoverStrike, Checkered Flag, Wolf3D, Doom) use the blitter for polygons (maybe Skyhammer doesn't?). Bottom line: I claim I could expand the resolution of any polygon game that uses the blitter for all of its polygon generation, add texture filtering, and do it faster than any software emulated approach. 3D chips are beaucoup fast these days with HUGE input bandwidth.
  17. Actually, if someone else wrote the emulator, and they wanted to tap me to write this part of it down the road, I'd be interested. Just give me an interface and I'll write the rest. I'm thinking that just by looking at the usage patterns of the blitter, I could tell the difference between a polygon engine and a sprite game, and from there, I could jack up the resolution to whatever anyone wanted, turn on anisotropic texture filtering, and all sorts of other goodies. But ya see, I have no interest in writing the entire emulator, just this tiny part. So I figure I'm safe for a good long time. My guess is that wouldn't murder the framerate at all... The video card would become an effective co-processor that instantly returned from all blitter calls as it batched up blitter commands as triangle pairs. The only issue would be when someone tried to write to/read from video RAM with one of the processors. BattleSphere, for example, directly wrote radar dots and targeting lights into video RAM as opposed to blitting it in there. I'm sure other apps did similar things. However, since one can lock subrectangles of target textures, this ought not be so bad: just queue up the memory accesses (all writes could be expressed as triangle pairs as well), and transmit them whenever someone tries to read back the RAM, then lock the subrectangle of the render target that is getting read.
  18. You're forgetting the ATI Radeon 9700 which is also DirectX 9 compliant. If you take a look at some of the sheer insanity that has been hacked already with vertex and pixel shaders in DirectX 8 level hardware, I'm not entirely convinced this is is so. One could potentially express each blitter command as triangle pairs (blitter commands are essentially quads or memory copies), pack them into a dynamic vertex buffer, and send it off to the hardware. The major problem is that there's no looping or flow control in DirectX 8 shaders. Whenever a frame is complete, a similar process could composite the framebuffer data, once again freeing up the x86 CPU to emulate the three main processors. Now you're probably thinking this is horribly inefficient, but just how many blitter commands can you send to the jaguar per frame anyway? As the author of a jaguar polygon engine of some reknown, I'd say it's vastly less than what you could pump into a GeForce 3 or Radeon 8500 per frame (about 20 million of them per second so unless you can fire off a blitter command every cycle, you're just dandy). The upside of this is that you could arbitrarily mess with the resolution and the texture data (You'd effectively use one big texture and then grab bits and pieces of it and with a maximum texture dimension of 2048x2048, you could fit the jaguar's entire RAM into a single texture). Where the whole thing would clog up is if the game interleaved polygon code with direct writes to the framebuffer RAM wherein the whole thing would flip flop on itself. But again, 300 MHz 3D cards are a lot faster than a 13.3 MHz data bus so there's some room for slop. The problem with me is that I get obsessed with the seemingly impossible. I have this really funny feeling you could do a lot more with 3D cards and the jaguar than at first thought if only because of the amazing performance of those suckers. Fortunately, my common sense kicks in before I try to write one of these things.
  19. Well, not really, it would/should run on any DirectX 9-capable graphics card. If it didn't, it would mean the driver was buggy (Hi, ATI!). The upside and the downside is that it would force you guys to actually buy a new 3D card rather than demand optimal performance out of your 1998-issue Voodoo II, Rage, or TNT. I, of course, have multiple ulterior motives for such a forced upgrade path >-)... And yeah, I know, DX9 hasn't even shipped yet...
  20. Except of course that if you have a DirectX9 capable 3D card, it's likely you actually could run the object processor and the blitter there. It'd be a headache to derive the representation, but you could do it, and I suspect it would be beaucoup fast. The only place this falls flat on its face is when the GPU/DSP/CPU need to write to video memory and then the whole thing would hang. Still, locking small areas of memory for the writes might be doable. You could set up the processor to trigger an exception if the x86 CPU touched those ranges. Oh the things I would do with inifnite time and alternate versions of myself. So I suspect I would limit it to the object processor and then upload its active memory ranges to the thing every frame as textures.
  21. Dude, do yourself a favor: don't argue tech with Doug... He's right, he's pretty much always right about such things, and all you're going to do is bring out his snarky side if you persist... And then you're going to complain about how rude he is... Just remember you brought it on yourself if you go there...
  22. That's easy guys: download and install FRAPS at http://www.fraps.com/...
  23. Right now, BS faw down and go boom on Project Tempest... Don't put that cart before the horse...
  24. Sadly, ATI cards in general are sabotaged by their crappy drivers. And it's a damned shame because their hardware is quite nice with some really clever performance tricks built into them. Sounds familiar somehow, doesn't it? And remember, you can't spell Atari without A T I...
×
×
  • Create New...