Quantcast

Page 100 of 145 FirstFirst ... 509096979899100101102103104110 ... LastLast
Results 1,486 to 1,500 of 2166

Thread: Advantages of SNES hardware vs. Genesis hardware

  1. #1486
    Smith's Minister of War Hero of Algol Kamahl's Avatar
    Join Date
    Jan 2011
    Location
    Belgium
    Age
    29
    Posts
    8,424
    Rep Power
    137

    Default

    You can use the 4 palettes freely.
    This thread needs more... ENGINEERS

  2. #1487
    Raging in the Streets Yharnamresident's Avatar
    Join Date
    May 2013
    Location
    British Columbia
    Posts
    3,298
    Rep Power
    56

    Default

    Yes Kool Kitty, its more of the 15-bit palette that makes more of the difference. If you all got 4-bits per sprite, theres not that much of a difference there.


    And I wonder how the palettes are defined.

    Maybe its in arrays:

    palette1 = []

    palette1[0] = #FFFFFF

    palette1[1] = #060606

    palette1[2] = #000000


    But of course you can't use Python in a 20 year old console.

  3. #1488
    Wildside Expert
    Join Date
    Feb 2012
    Posts
    104
    Rep Power
    10

    Default

    Quote Originally Posted by Black_Tiger View Post
    Can someone who has actually programmed Genesis graphics please specifically define how Genesis color palettes are used?
    Kamahl is correct, but just to sum it up.

    - CRAM ( color RAM ) entries are 9-bit ( 0-511 ).
    - The total amount of CRAM ( 72 bytes ) is divided over 4 palettes with 16 colors each.
    - Each sprite and tile has a 2-bit ( 0-3 ) color palette attribute.
    - Any pixel using color 0 ( regardless of palette ) is treated as transparent*
    - The background color can be any of the 64 colors.

    *This means that for sprites & tiles you effectively have 15 colors per palette ( 60 colors in total ), and that generally 3 ( or 4 ) CRAM entries are unused.

    Quote Originally Posted by azonicrider View Post
    And I wonder how the palettes are defined.
    You mean palettes on the MegaDrive / Genesis? If so, because the CRAM is accessed using 16-bit words, the palette data is read / written in a different format ( ----BBB-GGG-RRR- ) then how it's actually stored in CRAM. Using that 16-bit format, Red is #00E, Blue is #E00 etc.

  4. #1489
    Hero of Algol kool kitty89's Avatar
    Join Date
    Mar 2009
    Location
    San Jose, CA
    Age
    30
    Posts
    9,724
    Rep Power
    63

    Default

    Quote Originally Posted by Kamahl View Post
    You can use the 4 palettes freely.
    Yep, though in hardware it's actually seen as 4 sprite palettes and 4 BG palettes, but the CRAM entries are mirrored to both locations, so you have the same set of palettes shared. (cost/practical chip space constraints limited CRAM, of course) Similarly, the VDP is set up for 12-bit palette entries, but only 9-bits are actually used. (due both to CRAM space issues AND video DAC resolution in this case)

    This is also part of why the MD VDP can be expanded as it was in the System C arcade board, allowing 4+4 palettes of 15 colors from 12-bit RGB (4096 colors).
    And, as has been discussed before, the MD could have had support for that expansion too if those VDP lines had gone to the cart slot and/or expansion port. (so you could have color enhancement without using an entirely new VDP as in 32x, and if you DID add another VDP, you'd have better control over mixing the MD layers than the analog method the 32x used -the pixel bus provides added information on sprite/bg priority)
    6 days older than SEGA Genesis
    -------------
    Quote Originally Posted by evilevoix View Post
    Dude it’s the bios that marries the 16 bit and the 8 bit that makes it 24 bit. If SNK released their double speed bios revision SNK would have had the world’s first 48 bit machine, IDK how you keep ignoring this.
    Quote Originally Posted by evilevoix View Post
    the PCE, that system has no extra silicone for music, how many resources are used to make music and it has less sprites than the MD on screen at once but a larger sprite area?

  5. #1490
    Master of Shinobi evilevoix's Avatar
    Join Date
    Apr 2011
    Location
    Jerzy Shore
    Posts
    1,673
    Rep Power
    45

    Default

    I know I've brought this up several times so please spare the flames but Toy Story on the Sega Genesis displays well over 200 colors in screen at once on the MD during a still screen shot of the scenes in the movie. Is there any way to exploit that say in a background of an RPG, I know it isn't anything dynamic but still.


    Also back to the PCE, that system has no extra silicone for music, how many resources are used to make music and it has less sprites than the MD on screen at once but a larger sprite area? Is that an advantage or disadvantage?

  6. #1491
    Hero of Algol
    Join Date
    Aug 2010
    Posts
    7,668
    Rep Power
    173

    Default

    Quote Originally Posted by evilevoix View Post
    I know I've brought this up several times so please spare the flames but Toy Story on the Sega Genesis displays well over 200 100 colors in screen at once on the MD during a still screen shot of the scenes in the movie. Is there any way to exploit that say in a background of an RPG, I know it isn't anything dynamic but still.
    FTFY

  7. #1492
    Wildside Expert
    Join Date
    Feb 2012
    Posts
    104
    Rep Power
    10

    Default

    Quote Originally Posted by evilevoix View Post
    Toy Story on the Sega Genesis displays well over 200 colors in screen at once on the MD during a still screen shot of the scenes in the movie. Is there any way to exploit that say in a background of an RPG, I know it isn't anything dynamic but still.
    Toy Story uses sprites ( that utilize shadow / highlight mode ) to overlay the movie-stills entirely. You can't do this for a entire background in a game ( due to scanline and sprite constraints ).

  8. #1493
    ESWAT Veteran Chilly Willy's Avatar
    Join Date
    Feb 2009
    Posts
    6,744
    Rep Power
    77

    Default

    Quote Originally Posted by evilevoix View Post
    Also back to the PCE, that system has no extra silicone for music, how many resources are used to make music and it has less sprites than the MD on screen at once but a larger sprite area? Is that an advantage or disadvantage?
    The PCE sound generation is built into the CPU. It has six channels of wavetable sound. The wave entries are not very big - only 32 words of 5 bits each. Each channel has its own volume control, so you can do envelopes manually using the CPU and a timer. So you would set the timer to whatever period you needed for updating the wavetable envelopes, and every so many updates, you would process the music score. It's actually quite good, but many people just used plain square waves and sawtooth waves, so those wouldn't sound any better than the PSG in the SMS. With the right wavetable values and envelopes, you could make all kinds of decent instruments on the PCE. Instruments with simple repeating waveforms (pianos, guitars, organs, synths) can sound really good. Not simple and non-repeating instruments (like drums) are harder to do well. You can use the timer and the cpu to play PCM using the sound channels (5 bits using one channel, or 10 bits using a pair of channels), but that takes a lot of CPU time.

    The sprite limit on the PCE is exactly the same as the MD in 256 wide mode - 64 total with 16 on a single line. Other than using 16x16 tiles, there doesn't seem to be any advantages to one console over the other. The main one for each console is - the MD can do 80 sprites/20 per line in 320 wide mode, while the PCE has 16 palettes for sprites (to the MD's 4 palettes). The MD's 8x8 tiles can save space over the PCE's 16x16, but the PCE can do taller sprites (64 vs 32). In the end, it's mostly more sprites (MD) vs more colors (PCE).

  9. #1494
    Hero of Algol kool kitty89's Avatar
    Join Date
    Mar 2009
    Location
    San Jose, CA
    Age
    30
    Posts
    9,724
    Rep Power
    63

    Default

    Quote Originally Posted by evilevoix View Post
    I know I've brought this up several times so please spare the flames but Toy Story on the Sega Genesis displays well over 200 colors in screen at once on the MD during a still screen shot of the scenes in the movie. Is there any way to exploit that say in a background of an RPG, I know it isn't anything dynamic but still.
    As addressed above, it's not over 200 (though, technically that's possible too), but with the specific method used in Toy Story, no it's not really practical in-game. For an RPG style setting, there are some possibilities for more color (or more flexible color usage) though. If you limited things to a single scrolling BG plane (so like PCE) you could do up to 31/32 colors per tile using any pair of the 4 palettes available. (but that uses 2x as much VRAM space for tiles . . . at least if you use 31 color tiles for EVERYTHING -more slective use and more careful re-use of tiles in art could make it more practical though, however most of these would follow the same argument for the SNES using mode 3 with 241 colors usable per tile, except the MD has better DMA bandwidth for VRAM updates and more CPU resource for compression without added hardware)

    Additionally there's the per-tile shadow effect that could be useful for certain art styles. (doesn't hurt memory usage or layers, but just isn't that useful since it just makes colors 1/2 as bright on a per-tile basis)

    You could also use sprite "decals" in moderation (with or without shadow/highlight) for more flexible art design as well. This could work well in RPGs and overhead adventure games. (Novotrade's Jurassic Park: The Lost World does this, along with using paired BG layers, per-tile shadow, and a lot of dithering -though it's also pretty fine dither, so it blends pretty well) The Lost World example doesn't really reflect the typical JRPG art style, so it's somewhat up to the imagination as to just how that could have looked.


    Also back to the PCE, that system has no extra silicone for music, how many resources are used to make music and it has less sprites than the MD on screen at once but a larger sprite area? Is that an advantage or disadvantage?
    OK, wow, evilivoix, you've done it again . . .

    Anyway, Chilly addressed this pretty well already.





    Quote Originally Posted by Chilly Willy View Post
    You can use the timer and the cpu to play PCM using the sound channels (5 bits using one channel, or 10 bits using a pair of channels), but that takes a lot of CPU time.
    That also depends on exactly what sort of samples you're pushing . . . and compared to the MD, you've at least got interrupt signals for timing to make things more foolproof than many Z80 sample drivers show. (not "better" per se, but easier)
    That said, you're also limited to 6.99 kHz max for the internal timer (or 15.7 kHz using scanline interrupts -more overhead there too though), though it also would have been possible to include timers on hucards. (would have been nice of the CD expansions added that too . . . OTOH there's an even better argument that they should have used a simple DMA PCM circuit instead of the ADPCM decoder, but that's another story )

    Tomaitheous described a good interrupt PCM driver taking roughly 50 cycles per sample on the PCE, so a single channel 7 kHz driver would use about 4.9% of the CPU time (7.16 MHz), though I forget what resolution this was in the context of. (doing packed 5-bit PCM would be more intensive than unpacked, or packed 4-bit -especially with LUT, or 8-bit -though the latter still has the overhead of writing the upper and lower 4 bits to separate channels, but probably no worse than unpacking 4-bit PCM -unpacked 5-bit would be the fastest though) That's all just 1 channel playback and without scaling, of course. (so no pitch control or such . . . though simple power of 2 scaling would be easy -not good for notes, but maybe some SFX)
    7 kHz is pretty low for doing a MOD player anyway, but it's OK for SFX and drums (not bad compared to average MD examples).
    Doing 2 channels that way also wouldn't be unreasonably CPU intensive for most things. You could probably handle simple DPCM or ADPCM decoding fine too, but without higher sample rates there isn't a how lot of point to that. (4-bit linear PCM is pretty well suited to 7 kHz and below, ADPCM or DPCM variants aren't really worth it for that . . . except maybe 1 or 2-bit formats if you had REALLY low bitrate constraints, but again probably not worth it -unless you really needing something on the level of low bitrate NES style 1-bit DPCM -doing a stepped 4-bit format might be better for SNR for some things though, like 4 bit mapped to 5-bit, and about the same as decoding 4-bit via LUT)
    6 days older than SEGA Genesis
    -------------
    Quote Originally Posted by evilevoix View Post
    Dude it’s the bios that marries the 16 bit and the 8 bit that makes it 24 bit. If SNK released their double speed bios revision SNK would have had the world’s first 48 bit machine, IDK how you keep ignoring this.
    Quote Originally Posted by evilevoix View Post
    the PCE, that system has no extra silicone for music, how many resources are used to make music and it has less sprites than the MD on screen at once but a larger sprite area?

  10. #1495
    ding-doaw Raging in the Streets tomaitheous's Avatar
    Join Date
    Sep 2007
    Location
    Sonoran Desert
    Age
    43
    Posts
    3,981
    Rep Power
    75

    Default

    Slightly off topic on PCE sound. Wall o' text!

    PCE can use a channels buffer to play higher frequency sample streams than 7khz driver. There are two revisions of the CPU (6280 and 6280A). The newer revision CPU fixes an issue of a pop/spike on a channel when you go from full volume to 'off'. So, normally you can't just fill the buffer and turn the playback back on for that channel with out a 7khz tone (and it's loud). A work around, which works on both cpus, is to use two channels to stream 32 bytes at a time. The direction of the 'pop' is directly relative to the direction of the volume change. That is to say, full to zero volume creates a complete opposite output spike than from going to zero to full. So simply switching between channels and turning on off and the other on at the same time, cancels out the pop. Thus, you could in theory do 7khz x 32 byte or 224khz playback. Though resource wise, it'd be better to do 1khz timer (you can set the divider to get lower interrupt intervals in hardware, or just do a software down counter on the main at fill timer speed) and get 32khz. You can interleave two channels for that, so two 16khhz channels playing at 5bit PCM. I.e. you get you other channel back, per se.

    I have a 7khz MOD player (someone else wrote it; it's a private release) and I have my own MOD driver for a 4 channel at 7khz as well. Some mods sound like crap, but some sound pretty decent. It all depends on the samples being used. One trick is to have an alt set of samples for the higher octaves, because simply 'skipping' samples to get higher playback rates for 'looped' samples introduces clicking artifacts. The clicking is soft, but it's there. Makes the looped part (if short) sound a little gritty because it's never always on the example same sample re-point (fixed point counter skipping samples). 3 MOD channels along with 3 normal channels would make for a decent sound engine IMO. And that would keep the resource below 15% cpu resource IIRC.

    I have a 16khz 10bit sample playback routine that uses 22% cpu resource: http://www.pcedev.net/16khz/16khz.htm That's better than the GBA mod players they used in games like FF 2/3US remakes (they were ~7-8khz at 9bit PCM). That's enough for 4 channels at 8bit PCM with soft volume LUT, without overflow (or more channels if some where dropped to 7bit and some kept at 8bit). You're probably looking closer to 40% cpu resource for 6 or so channels, but that's totally doable for something like an RPG.


    As far as regular channels, you can do timbre changing on an inter-note basis but you'll get some clicking because you don't know where the sample pointer is - on the channels buffer. So the restart for the new sample gets a 'click' sound. Bloody wolf does this to the saw tooth channel to smooth it out (the trumpet-ish instrument used through out the game), thus the slightly gritty sound of BW. But the music is very 'busy' sounding, so it help masks it. Doing note-to-note timbre changing is easy though and a few PCE games employ it ( here's an extreme example I did using ripped R-TYPE channel waveforms from the rom: http://www.pcedev.net/audio/pce_rips/R-type.xm ). At lower frequencies, you can make some interesting sounds by updating the channel waveform buffer without turning off the channel, that don't have that audible clicking sound: http://www.pcedev.net/audio/bloodywolf/BW_test1.mp3 - http://www.pcedev.net/audio/bloodywolf/BW_test2.mp3 - http://www.pcedev.net/audio/bloodywolf/BW_test3.mp3 . I wrote a BW sound engine that did what the game did, but altered the pitch envelopes and waveform change envelopes to create a few different sounds. That 'yeeaaahhhh' sound is not a streaming sample. You can play it in different note pitches too, just like a regular instrument.

    There's another trick you can do for creating timbre changes too. The PCE doesn't have any problems changing a channels period/pitch in realtime, like some older sound chips of the 80's. Vibrato and LFO and pitch slides can easily be done by the cpu in software. Some sound chips have 'clicks' when you change the MSB independent of the LSB, the 6280 does not. Now, almost all PCE games use detune, along with vibrato, to get some variant change of the timbre over time. It's not as pronounced as something like FM or such for note timbre bending, but it gets the job done and doesn't sound so sterile. I came up with a track that involves something akin to detuning, but also combined with waveform adding/subtracting. In principle it sounds easy, but in practice it's very sensitive to timing and parameters. Basically you reserve one channel for phase and subtraction. And another channel for carrier. The carrier only uses positive PCM sample values in the buffer. The phase channel only uses negative PCM values in the channel buffer. A custom volume envelope is used on the modifier channel. When the volume is raised, the waveform from the modifier channel starts to subtract from the carriers waveform (waveforms accumulate). This alone isn't a very strong effect (from what I've tested), but noticeable. To further it along, I use phase shifting. Normally, detune causes phase shifting because one channel drifts out of tune from the other channel. But that's it; you have no control once it's set in motion. The idea I came up with is to bump a second channels frequency to get it out of phase, then quickly set the channel's frequency back in sync with the primary's. I now have full control over the phasing between two channels. I can even have it sway back and forth and such. The key is that the two channels need to be in near perfect sync, and this is doable on the PCE because while you *can't* read the channel waveforms pointer position to know where it is, you ~can~ reset it back to zero at any time (done a lot of tests on this. You can even do this while the channel is playing, without turning it off or effecting the volume. Which means you can do hard-sync effects on a channel with the TIMER interrupt). Now, you waste a channel to do this effect. But you only need one channel. You can play a three note chord with only using 4 channels. The effect on the timbre is strong enough that you don't need to replicate it for the other two channels; thus I present you with this - http://www.pcedev.net/audio/chord_scale.wav . Note, you need to change the amount in the phase shift depending on the octave the instrument is in. In the example I provided, I didn't so you can hear where it starts to sound wobbly or not as pronounced in the upper octave ranges.

  11. #1496
    Smith's Minister of War Hero of Algol Kamahl's Avatar
    Join Date
    Jan 2011
    Location
    Belgium
    Age
    29
    Posts
    8,424
    Rep Power
    137

    Default

    Any chance you can post some MODs running on the PCE? I'd love to hear what it sounds like.
    This thread needs more... ENGINEERS

  12. #1497
    Master of Shinobi evilevoix's Avatar
    Join Date
    Apr 2011
    Location
    Jerzy Shore
    Posts
    1,673
    Rep Power
    45

    Default

    I was just a little unsure if the PCE had to
    Dedicate resources to produce music or not. It was explained above.

  13. #1498
    Hero of Algol kool kitty89's Avatar
    Join Date
    Mar 2009
    Location
    San Jose, CA
    Age
    30
    Posts
    9,724
    Rep Power
    63

    Default

    Ah, neat, I'd forgotten about the on-chip 32x5-bit PCM buffers, that's pretty useful for PCM buffering. Just sync up the interrupt routine with the sample rate (and probably double buffer), and you're good. (well, and working around the pop issue you mentioned)
    That would also cut down on interrupt overhead (fewer interrupts for higher playback rate), though that's not a huge deal given the inherently low interrupt overhead for 650x. (would be a bigger deal for something like the 68k, more so depending how you managed the registers for the routine)
    6 days older than SEGA Genesis
    -------------
    Quote Originally Posted by evilevoix View Post
    Dude it’s the bios that marries the 16 bit and the 8 bit that makes it 24 bit. If SNK released their double speed bios revision SNK would have had the world’s first 48 bit machine, IDK how you keep ignoring this.
    Quote Originally Posted by evilevoix View Post
    the PCE, that system has no extra silicone for music, how many resources are used to make music and it has less sprites than the MD on screen at once but a larger sprite area?

  14. #1499
    Master of Shinobi evilevoix's Avatar
    Join Date
    Apr 2011
    Location
    Jerzy Shore
    Posts
    1,673
    Rep Power
    45

    Default

    It's just vague is all. From what I have been reading on the Forums and simply asking for clarification is enough trouble. The sound was where I was off on this system. Sprites, who the fuck argues sprite area vs sprites? That was a copy past from PCFX, they get real heated over there.
    Last edited by evilevoix; 08-11-2013 at 11:22 AM.

  15. #1500
    ESWAT Veteran Chilly Willy's Avatar
    Join Date
    Feb 2009
    Posts
    6,744
    Rep Power
    77

    Default

    Quote Originally Posted by evilevoix View Post
    It's just vague is all. From what I have been reading on the Forums and simply asking for clarification is enough trouble. The sound was where I was off on this system. Sprites, who the fuck argues sprite area vs sprites? That was a copy past from PCFX, they get real heated over there.
    They argue sprite area because the PCE only has one background layer. You can get around that somewhat by using the sprites as a second layer. I believe that's probably why most PCE games are 256 wide even though the PCE can do 320 or even better - the sprite "layer" can only be 256 pixels, which would only act like a second layer if your game was also 256 wide.

Thread Information

Users Browsing this Thread

There are currently 2 users browsing this thread. (0 members and 2 guests)

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •