Talk:Ballz
From Wikipedia, the free encyclopedia
 |
This article is part of WikiProject Computer and video games, an attempt to build a comprehensive and detailed guide to video games on Wikipedia. If you would like to participate, you can edit the article attached to this page, or visit the project page, where you can join the project and/or contribute to the discussion. | |
| Start | This article has been rated as Start-Class on the assessment scale. | |
|
CVG To-do:
|
||
[edit] Sega DSP chip
I worked on Ballz. I have no recollection of any special "DSP chip" being added to the BOM for the Sega or SNES cartridge to address tearing issues. Source? --Tedbarnett
- The source is me. Sorry, I know we prefer sources we can reference, but I worked on the game too (I was a tester at Accolade at the time). The Sega version was great (well, they both were, really), but suffered from a great deal of sprite breakup. Sega said it'd have to be fixed before they gave it their approval. Apparently, the only way to do this was to add a DSP chip to the cart. The extra cost meant they had to cut something else, so they eliminated a number of sound effects (meaning they could cut one ROM, reducing cost). It was changed late in the production process, after it had been submitted to Sega once. What part of the game did you work on?
- Please sign your posts. You can do this with 3 or 4 tildes (~~~ or ~~~~). The latter is preferred, as it also adds a timestamp. — Frecklefoot | Talk 14:38, 24 October 2005 (UTC)
Dont you guys mean the Nintendo version? That one DID came with a DSP chip.
- I'm quite sure you actually mean the SNES version. That one definitely had 8 MBit and a DSP chip, the SEGA version had 16 MBit. I've never heard about a DSP in the SEGA game before reading this "article". And there is still some sprite breakup in the Genesis version... doesn't look like they used a DSP. What do you think? -- Simon
-
- Well, it's been a long time, but memory says it was the Sega version. But it could've been the SNES version. Whichever version it was, I think it was better with all the sound effects, sprite breakup notwithstanding. BTW, where did you hear about the SNES version having a DSP chip? It's not like it was announced on the packaging or anything. — Frecklefoot | Talk 16:32, 17 May 2006 (UTC)
-
-
- DSP chips have been an issue for authors and users of SNES emulators for years, and for copier users years before that. Apart from a few extremely obscure Japanese titles, it's well-documented which games use DSP chips, and which ones they use (google something like "Ballz SNES DSP" and you'll get hundreds of pages). By contrast the only DSP chip anyone worries about on Genesis is the SVP (the chip used to do 3D rendering for Virtua Racing). --- Ex-Cyber
-
[edit] Sprite breakup
What is sprite breakup (at least I have a clue) and why does it occure? --Abdull 10:59, 21 April 2006 (UTC)
- Sprite breakup is when one frame from a sprite is drawn before another frame is "erased." It also occurs when a sprite starts to be drawn at a second location before it is "erased" from the first location. When this occurs, the sprite graphics appear jagged and flashy (in a bad way).
- It occurs when the second frame or new location is drawn out of sync with the vertical refresh of the elctron gun in the monitor. It's kind of technical, but a monitor or TV displays the screen's image with an electron gun (at least in CRTs, I don't know how plasma screens do it). It moves from top-left to bottom-right. As it is repositioning itself from bottom-right to top-left, it is called the "vertical refresh" time. During this time, sprites are typically moved to their new position or display a different frame. If done during this time, they are successfully "erased" and when drawn on the screen on the next pass, look just as they should, with no breakup. If, however, a game changes the sprite's location out of sync with the veritcal refresh, sprite breakup can occur.
- This is usually how sprite breakup occurs. But for Ballz, I think the breakup was a result of noisy DMA or some other thing. Otherwise, I don't know why they'd need a DSP chip. Anyway, hope this helps. — Frecklefoot | Talk 16:08, 21 April 2006 (UTC)
-
- Genesis and SNES graphics don't work like modern computer platforms - to the extent that sprites must be "erased", this is handled entirely by the sprite hardware. On Genesis sprite glitches are usually the result of having too many sprites on the same display scanline; regardless of the number of sprites that can be defined in VRAM, there is a limit as to how many sprite pixels can be displayed on one line, and exceeding that limit causes sprites over the limit to simply disappear wherever they overlap with the overcrowded lines. SNES has a much higher limit (its sprite hardware works somewhat differently from the traditional model employed by the Genesis VDP). I strongly doubt that the DSP has anything to do with this; the Genesis version has no DSP, and the one used in the SNES version couldn't have done the graphics rendering as it implements a high-level set of geometry manipulation routines. The internal code is fixed (i.e. a developer was not able to directly program the DSP engine with game-specific code) and it was intended for implementing games like Pilotwings and Super Mario Kart that needed to do more geometry calculations (primarily for generating the control values for the rotating/scaling background) than the weak SNES CPU could handle, not for rendering sprite-heavy games. --- Ex-Cyber
- Well, like I think I stated, I was only a tester on this title, not a programmers and I just got the technical mumbo-jumbo from the lead tester, who probably converted what PF Magic told him into something he could grasp. When I asked him what the DSP chip was for, he said "I don't know," except that it related to sprite breakup.
- Thanks for your input, Ex-Cyber, but please get an account (it's free) and sign your name (with 3 or 4 tildes (~~~ or ~~~~). The latter form is preferred, since it also adds a timestamp. Cheers! — Frecklefoot | Talk 16:01, 8 September 2006 (UTC)
