   2D rendering - current best practice?
  Hi all,I have a Canvas base class that essentially has a couple of pure virtual functions such asvirtual void Init()=0;virtual void Clear()=0;virtual void Flush()=0;virtual void PutPixel(int x, int y, Colour c)=0;The application's going to be a testbed for different 2D canvases; I've stuck in my ASCII renderer to get me going.I was about to implement a VGA mode 13h canvas, until it transpired that this is so old a technique that my compiler and OS (VC++, Win 2K) won't let me.So, just what IS the current best practice for getting a fast 2D canvas I can implement PutPixel(...) on? Legacy DirectDraw? Or a textured quad in DirectX/OpenGL with orthogonal projection? Or GDI?I would quite like to implement all the above, but probably won't; what I would like to do is at least implement the fastest. So, how ARE the kids coding oldskool demos these days?   www.coldcity.comcode, pics, life[edited by - IainC on February 16, 2004 11:57:33 AM]
  Depends on your target.  If you are happy requiring hardware acceleration then I''d suggest ditching all ideas of individual pixel magic and go with a Direct3D or OpenGL system (using ortho projection etc.).  You get so many nice features essentially for free that you can then stop focusing on the low-level nitty gritty and build a good data-driven higher level engine (e.g. hierarchical sprites, tiling system or whatever). ;  However, if you _really_ want to be able to do individual pixel manipulation (i.e. something along the lines of a software 3D renderer, although you''re talking about 2D), then I''d advise you to go with DirectDraw.  Direct3D / OpenGL aren''t really geared towards manipulating individual pixels, so there''s no really good way to take advantage of the hardware acceleration unless you switch to what JuNC suggested and manipulate entire chunks. ;  Well, it''s really just a state-of-play update for me. I used to do some Amiga demo coding, and it occured to me how long it was since I had any old-skool fun, and it''s one of those nice-distraction-from-my-real-project sort of things.I''m not fussed either way about hardware acceleration; CPU cycles available per pixel are more important for the sort of thing I''m playing with.Can''t seem to find an implementation of the OpenGL/DX route similar to mine in encapsulation and simplicity - anyone know of one?   www.coldcity.comcode, pics, life ;  psykr - Thanks, that''s exactly the sort of advice I need. Do you know of any simple implementations to look at? Researching old DirectDraw code it seems often hard to figure out which DirectX version it was current with...   www.coldcity.comcode, pics, life ;  Have you checked out SDL (Simple DirectMedia Layer)?  It uses DirectX on Windows, and is a really light wrapper over it.  It''s easy to use, free(under the LGPL) and ''portable''!www.libsdl.org;  I found exactly the sort of thing I''m after here - but it does seem helluva slow  www.coldcity.comcode, pics, life ;  I too recommend SDL, it''s very easy and available for a number of platforms. Another library that''s specifically designed for what you''re doing is PTC, or tinyPTC which only has the functions to init/deinit video mode and blit graphics from a memory buffer to the screen. However, I haven''t used it so I can''t say anything about compatibility/stability etc. ;  Fingers_, TinyPTC looks awesome - I''ll probably go with that.I found someone doing exactly the same thing as me in a much nicer way - have a look at Mujaki (the guy also has some nice demo-coding notes)   www.coldcity.comcode, pics, life ;  Along the lines of SDL(if you prefer C anyways) is Allegro. Its nice and simple and supports a variety of platforms and interfaces.Check here: www.allegro.ccHope it helps,-Flecko   [edited by - Flecko on February 17, 2004 9:42:11 AM]