1

Just wondering - throwing ideas in my head - about starting a new XNA project for the 360. I would like it to be retro-old school, and emulating scanlines and color palettes and such.

As part of this idea, what I would ideally like to do is manually draw each and every pixel of the screen. So, worst-case scenario I would have to draw about 60K sprites on a 252x240 resolution (I think thats correct). 60K sprites on the screen at a time.

So, before I even attempt to code this - would the XBOX 360 be able to keep up with this even? That is a lot of sprites, but they aren't big sprites, and the texture data needed would be non-existant. However, I guess how this project would be implemented would make it or break it, but all I was thinking was coming up with a 2D array and mapping which color value would need to be drawn at that point.

Of course, this is watered down talk right now. But what you all suggest?

EDIT: Each sprite would represent one pixel. E.g., a sprite at 0,0. Another at 0,1. etc.

McDowell
  • 107,573
  • 31
  • 204
  • 267
Jeffrey Kern
  • 2,024
  • 20
  • 40
  • Why not just draw your own textures? – Gabe May 31 '10 at 01:15
  • 4
    Erm... one pixel wide sprite is not a sprite, it's a pixel – Diadistis May 31 '10 at 01:15
  • 1
    @Diadistis: it's not a one pixel wide sprite, it's a sprite that represents 1 pixel. Note that he's talking about 252x240, not 1920x1080 ;) – Wolph May 31 '10 at 01:37
  • I'm going for emulating the graphical style of the NES, and the NES had hardware limitations on what could be done. Eg., only 8 sprites per scanline, only 24 colors per scanline, 3 colors per sprite, etc. (If I recall correctly, Wikipedia has all of this info). If I just draw my character sprites, it would work. But I couldn't emulate flicker among other effects, such as changing color palettes on the fly. – Jeffrey Kern May 31 '10 at 01:49
  • 2
    Can't tell you about XBox360 performance, but this "Each sprite would represent one pixel. E.g., a sprite at 0,0. Another at 0,1. etc." Is a VERY bad way to do things. Don't do it. Ever. Especially if you're going to store each one sprite as a separate entity. With PC and DirectX 9 you are guaranteed to get slowdown due to call CPU overhead. Most likely platform won't handle this. Also you really need to read this: http://msdn.microsoft.com/en-us/library/ee418872(VS.85).aspx – SigTerm May 31 '10 at 02:00
  • @SigTerm: think you're misunderstanding the OPs "pixel" term. His "pixel" is actually a sprite with dimension 7.6x4.5 real pixels... – Peter Lillevold May 31 '10 at 10:34
  • @SigTerm: While this is true for vanilla D3D the XNA FX provides a SpriteBatch class that will result in one DIP call for a large number of sprites that use the same texture and other states (for 60k it might be around 4 DIP calls). However, this doesn’t really seem to be the best way to do an emulator like thing: a better option might be to use a dedicated 252x240 texture (with a buffer to set the pixels and Texture2D.SetData) and use a stretch draw call to call them at once. – Björn Jun 02 '10 at 03:30
  • @Bjoern I tried doing that. It took like a minute just to do enough Texture2D.SetData calls to render just one frame of info to the texture. :P – Jeffrey Kern Jun 02 '10 at 19:31
  • 1
    @Jeffrey You do not, under no circumstances, call Texture2D.SetData more than a handful of times per frame :) Set the pixels in a Color array and SetData that array and so all pixels at once. – Björn Jun 06 '10 at 06:32
  • Really? So how does the array work then? Like, item 0 in the array belongs to pixel 0,0. Item 1 belongs to 1,0? Etc? – Jeffrey Kern Jun 06 '10 at 20:37

1 Answers1

3

Instead of using 60K sprites, which is unlikely going to work, I suggest you draw primitive squares and give them the colors you need.

It's actually a part of 3D programming, but you drop the Z axis altogether and specify an orthogonal camera.

As a matter of fact, a square is a simple combination of two triangles. I'm not saying the solution is quick and easy, but I think this is where you should start your research.

60K sprites is not a good idea.

SiN
  • 3,704
  • 2
  • 31
  • 36
  • 1
    This probably would be the best answer, as most consoles are capable of handing 120,000 triangles a frame :D I'm just too lazy to implement this myself, so I'm doing another approach lol. But this probably would be the best method to do; I'm just not that good with 3D maths, but this might be useful to someone who is. – Jeffrey Kern Jun 02 '10 at 19:33
  • Well you don't have to be a Math freak. XNA handles all complex calculations for you. Anyway good luck! – SiN Jun 02 '10 at 19:35
  • 1
    It's worth pointing out that sprites, as implemented by XNA SpriteBatch *are* primitive squares - and the SpriteBatch shader is heavily optimised for drawing them quickly. Admittedly it does extra work like texturing - which could be removed here. If you wanted to use this method a good starting point would be modifying the SpriteBatch shader itself from http://creators.xna.com/en-US/utilities/spritebatchshader - Although this entire method is terrible - stick with pixel shaders, and if you must push that much data to the GPU, a texture would use less bandwidth than crazy per-pixel geometry! – Andrew Russell Jun 11 '10 at 04:42