It is currently Tue Oct 24, 2017 2:47 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 43 posts ]  Go to page Previous  1, 2, 3  Next
Author Message
PostPosted: Sun May 17, 2015 12:54 pm 
Offline
User avatar

Joined: Mon Sep 15, 2014 4:35 pm
Posts: 3075
Location: Nacogdoches, Texas
8bitMicroGuy wrote:
For me, retro isn't when the limits ruin your fun, but when you have full freedom on programming something 8-bit or 16-bit pixelated like Mario and when the hardware is dedicated for these stuff.

You mean like a tile based system? That's why I eventually plan venturing the unknown of the M92 or M107. They are both strong (with the M107 being stronger) and they are both 2D systems. Now that I think about it, I don't think there's ever really been a perfect 2D home system technical wise. I'd say the Sega Saturn, if it weren't for the slow CD technology and limited amount of vram. (Which is held back by the CD drive.) It also isn't great from a programming perspective from what I've heard and would immagine, but I'm not counting that. I'd say the most well rounded is the SNES, but it has a good deal of its own problems. That's why I plan to work on the M92 and the M107 eventually, but I will miss the special effects the SNES offers like transparency, even if some of them aren't the most practical.

8bitMicroGuy wrote:
I'll use devkitPro. I think it has devkitARM inside, right?

I think there's an installer, and it asks what you specifically want. If you chose everything, You'll get DevkitARM but you don't need to if that's all you want.


Top
 Profile  
 
PostPosted: Sun May 17, 2015 1:48 pm 
Offline

Joined: Thu Aug 12, 2010 3:43 am
Posts: 1589
Espozo wrote:
It also isn't great from a programming perspective from what I've heard and would immagine, but I'm not counting that.

It's much easier than people claim it to be, honestly I was looking at the SDK used by Sega and using it isn't really any more complex than say Allegro (well, pre-5.0 Allegro, that is), it even handles the second processor for you so you don't have to waste time thinking on doing optimized multithreading, and also nearly every tool at the time used N-gons so being stuck with quads wasn't as bad as it sounds. I guess the problem with the Saturn was that the VDP1 lacks support for some stuff the PS1 GPU can do natively (like alpha blending).

Programming it from scratch without Sega's SDK (which you'd need to do to stay legal) is a whole different issue, although again I imagine you don't have to use all of the hardware either (and you aren't doing 3D stuff so that's less complex calculations to deal with).


Top
 Profile  
 
PostPosted: Sun May 17, 2015 2:09 pm 
Offline
User avatar

Joined: Mon Sep 15, 2014 4:35 pm
Posts: 3075
Location: Nacogdoches, Texas
Sik wrote:
It's much easier than people claim it to be

People have always acted like the SNES was difficult to program for, but I haven't had a problem. (Save the 1/4 of vram for sprites.)

About the Saturn though, it was never really meant to be a 3D system, is that right? It seems like it supports sprites that can be transformed instead of actual polygons.


Top
 Profile  
 
PostPosted: Sun May 17, 2015 2:33 pm 
Offline

Joined: Thu Aug 12, 2010 3:43 am
Posts: 1589
Espozo wrote:
People have always acted like the SNES was difficult to program for, but I haven't had a problem. (Save the 1/4 of vram for sprites.)

Well, compared to the Mega Drive it is hard. Besides the CPU's instruction set requiring more verbose code, the format of hardware registers and tables can get really annoying sometimes (and don't get me on how you have to pass data around to the SPC700, the Z80 on the Mega Drive has it bad with the bank switching but in my opinion the SPC700 has it worse). It's much harder to get started from scratch, essentially.

Now, moving from NES to SNES would be like moving to heaven though.

Espozo wrote:
About the Saturn though, it was never really meant to be a 3D system, is that right? It seems like it supports sprites that can be transformed instead of actual polygons.

The PS1 GPU also doesn't know about 3D either, it only sees 2D polygons.

Honestly I get the impression it was always meant to do 3D, it's just that Sega underestimated how important it'd be and Sony went all out as well. Sticking to quads seems dumb now, but back then nearly everything used mostly (or even only) quads and many games of the time handled quads internally (it was still wild times for 3D gaming), so the idea was definitely appealing. Also it seems the second CPU was added just to handle 3D transformations and such to pass preprocessed 2D quads to the VDP1 (the same way the Z80 on the Mega Drive was left with the intention to handle sound).

Also don't get fooled on the fact that there are two VDPs, this is comparable to the two S-PPUs on the SNES: they handle completely different parts (in the case of the Saturn, VDP1 renders quads to the framebuffer, while VDP2 renders the tilemaps).

EDIT: also this post looks like going heavily off-topic ( ・・) Point stands, Saturn is easier to use than it sounds if you aren't trying to push it to its limits (but every system is hard if you're trying that).


Top
 Profile  
 
PostPosted: Sun May 17, 2015 3:03 pm 
Offline
User avatar

Joined: Mon Sep 15, 2014 4:35 pm
Posts: 3075
Location: Nacogdoches, Texas
Sik wrote:
Well, compared to the Mega Drive it is hard. Besides the CPU's instruction set requiring more verbose code, the format of hardware registers and tables can get really annoying sometimes

I've never had a problem, but I can see how somebody else could. I like having a little amount of registers because it's less to keep track of. (I wouldn't mind having a Z register like the 65CE02 though...) Really, nothing I've made so far has really warranted more than 4 registers. (I use direct page quite a bit now.)

Sik wrote:
Now, moving from NES to SNES would be like moving to heaven though.

Hmm... No one seems to complain about the NES though. (It has a lot more people programming for it.) The SNES seems far more appealing to program for, in my opinion.

Sik wrote:
The PS1 GPU also doesn't know about 3D either, it only sees 2D polygons.

I guess that could be why there's no perspective correction?

Sik wrote:
EDIT: also this post looks like going heavily off-topic ( ・・)

Oh well! :lol:


Top
 Profile  
 
PostPosted: Mon May 18, 2015 2:08 pm 
Offline

Joined: Sun Mar 08, 2015 12:23 pm
Posts: 251
Location: Croatia
So there isn't a fully functional 2D tile-based hardware system? Like isn't there a way to go around the sprites-per-scanline limit?


Top
 Profile  
 
PostPosted: Mon May 18, 2015 2:21 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6304
Location: Seattle
By definition, a 2d tile-based hardware system has a sprites-per-scanline limit.


Top
 Profile  
 
PostPosted: Mon May 18, 2015 2:53 pm 
Offline
User avatar

Joined: Mon Sep 15, 2014 4:35 pm
Posts: 3075
Location: Nacogdoches, Texas
lidnariq wrote:
By definition, a 2d tile-based hardware system has a sprites-per-scanline limit.

I wonder what kind of overdraw the After Burner arcade board (Sega X board I'm pretty sure) had... Also, does this mean that you could potentially see overdraw problems on the Saturn?


Top
 Profile  
 
PostPosted: Mon May 18, 2015 3:48 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6304
Location: Seattle
Ultimately, it's always about balancing time. All systems, regardless of whether it's scanline-based or framebuffer-based takes a certain amount of time to blit a certain number of pixels. In a framebuffer-based system, that affects the total number of polygons you can have in a scene, but you can make the tradeoff of dropping the total FPS in exchange for drawing more total things.

A tile-based system (not a quad-based system, mind) doesn't give the programmers the ability to make that exchange: there's no framebuffer, and so you only have the time of one scanline to figure out what you're drawing on that scanline. So for the NES you just always get 25% overdraw, because that's how the hardware was designed. This amount of overdraw is a fundamental property when the silicon is designed, and although it could be made arbitrarily huge, there's no point in wasting silicon on something that'll never be used.


Top
 Profile  
 
PostPosted: Mon May 18, 2015 8:26 pm 
Offline

Joined: Thu Aug 12, 2010 3:43 am
Posts: 1589
Espozo wrote:
lidnariq wrote:
By definition, a 2d tile-based hardware system has a sprites-per-scanline limit.

I wonder what kind of overdraw the After Burner arcade board (Sega X board I'm pretty sure) had... Also, does this mean that you could potentially see overdraw problems on the Saturn?

It was framebuffer based, at least the sprite part. Incidentally, this is exactly the same deal with the Saturn, framebuffer for sprites + dedicated tilemap layers.


Top
 Profile  
 
PostPosted: Mon May 18, 2015 9:00 pm 
Offline
User avatar

Joined: Mon Sep 15, 2014 4:35 pm
Posts: 3075
Location: Nacogdoches, Texas
Sik wrote:
It was framebuffer based, at least the sprite part. Incidentally, this is exactly the same deal with the Saturn, framebuffer for sprites + dedicated tilemap layers.

What was up with him saying this then?

lidnariq wrote:
By definition, a 2d tile-based hardware system has a sprites-per-scanline limit.

Are the objects that are being translated and scaled on the Sega X Board actually not considered sprites then? I do remember hearing something about how the frame buffer gets rotated instead of actual sprites though. I also remember hearing that the system didn't support tiles, but I thought they just meant BG tiles. So far, it doesn't sound like it could really be considered a sprite based system but rather a really limited PlayStation or something. After reading all this, it seems like the Neo Geo should have been built with this setup, but I'm sure it was expensive back then, and the Neo Geo isn't necessarily what I'd consider a Ferrari in terms of arcade hardware.


Top
 Profile  
 
PostPosted: Mon May 18, 2015 9:28 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6304
Location: Seattle
I was interpreting "hardware tile-based" as "just-in-time rasters" as opposed to "framebuffer".

Certainly there've been a number of other systems that have hardware-accelerated bitblits with transparency to a framebuffer without scaling or rotation.


Top
 Profile  
 
PostPosted: Tue May 19, 2015 4:42 pm 
Offline

Joined: Sun Mar 08, 2015 12:23 pm
Posts: 251
Location: Croatia
Alright. How about sandwiched tile-based system?
Buffer-tiles-buffer-tiles-buffer-tiles-buffer-tiles-buffer.
This way you'll have 4 tile layers and 5 buffers for sprites that you can transform however you want.
Does this exist?


Top
 Profile  
 
PostPosted: Tue May 19, 2015 5:15 pm 
Offline
User avatar

Joined: Mon Sep 15, 2014 4:35 pm
Posts: 3075
Location: Nacogdoches, Texas
8bitMicroGuy wrote:
Alright. How about sandwiched tile-based system?
Buffer-tiles-buffer-tiles-buffer-tiles-buffer-tiles-buffer.
This way you'll have 4 tile layers and 5 buffers for sprites that you can transform however you want.
Does this exist?

Not that I'm aware of. If it does, it's probably one of Sega's inventions. I know that none of the super scaler series of arcade boards do, but I'd imagine the System 32 would be good enough: segaretro.org/Sega_System_32


Top
 Profile  
 
PostPosted: Tue May 19, 2015 5:48 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19122
Location: NE Indiana, USA (NTSC)
Nintendo DS has a sandwich.

The GBA PPU has four tiled layers, and each two can be replaced with a mode 7 layer, or all four can be replaced with a software-drawn frame buffer. Games using 3D rendering, such as Doom and Payback, use a frame buffer mode.

The DS has an upgraded GBA PPU that has two fixed-function tiled layers and two layers that can be switched among tiled, mode 7, or a frame buffer. It also has a 3D unit that renders to a 48-line-tall circular buffer and supports about 6,000 vertices (1,500 triangle or 2,000 quads) per scene. Most games just send this circular buffer directly to one of the screens; others use half of the system's 512K texture RAM for a pair of frame buffers so that they can push more polygons (at a frame rate cost) or do 3D on both screens.


EDIT: I left a word out


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 43 posts ]  Go to page Previous  1, 2, 3  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 2 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group