Personally I'd recommend grabbing an old copy of qbasic with dosbox and going to town on some old tutorials here http://www.petesqbsite.com/sections/tutorials/graphics.shtml

I know some would say it's a bad language, but back in the day it was incredibly accessible and spawned a lot of shared code and tutorials. If you focus on the techniques and algorithms, treat the language as pseudocode rather than "the right way to do things", you can have a lot of fun and learn quickly things you can translate to whatever your language of choice is.

I think most of those will work on QB64, too. So you could end up end with fast, native executable files on Windows, MacOS, and Linux. That doesn't matter much for those tutorials, but QB64 might be ever so slightly quicker to get up and running than DosBox + QBasic.

Great point! I had forgotten about QB64. Heck, I may give it a go myself. This thread gave me an itch for software rendering again.

Javascript + HTML5 Canvas is an easy start, and if you want to do even older-skool stuff you can treat the canvas as just a block of pixels and write your own 2D renderer on top of it.

Go with Processing, the API is very simple, and YouTube has plenty of videos demoing various projects:

https://www.youtube.com/user/shiffman

Processing is amazing (and what I switched to after I started hitting Flash performance limitations). They have great documentation and tutorials on their website too, and I felt it's little IDE made it really easy for beginners to get started with it.

> I really just want to put pixels on the screen and work my way up from there

That really isn't how modern, accelerated graphics works - even 2D accelerated graphics! "Sprites" are slightly closer to the mark, but it goes far beyond that.

The PC never had sprites

The entire framebuffer can be thought of as a huge sprite. Modern RAMDACs can scan multiple overlapping arbitrarily sized framebuffers (layers) simultaneously, while doing bilinear filtering, merging alpha, colorspace conversion, rotation, LUT, etc.

All that happens on the fly without intermediary frame buffer composition in between. The output goes directly to the display (over HDMI, eDP/displayport, DVI, etc.).

Yeah, and of course mouse cursor is a sprite in the traditional sense. Although on modern HW you could implement mouse cursor as a hardware layer.

Isnt the mouse pointer actually a hardware layer in most OSes nowadays?

Yeah, it is. Sprite originally meant a hardware layer, back from the ancient times. Nowadays it also sometimes means rasterized 2D objects.

C64, Amiga, MSX, NES, SNES, Sega Master System, etc. all supported hardware layer sprites back in the eighties.

What's the difference? Size? If a hardware layer could be configured to be 32x32 pixels and offset to any position, wouldn't it become a sprite?

If you're using a decent graphics driver, the mouse pointer is a sprite.

You can do it with SDL or even just Canvas and JS. Later on you'll converge onto "3d as 2d" as you try to optimize and leverage shaders for high performance effects like color grading, blur, glow, etc.

I've been dabbling with 2D graphics recently and found PyGame to be well suited for experimentation. You'll need to hold your nose a bit (API is a bit clunky in places and far from Pythonic) but it's relatively trivial to get some pixels on screen.

Start with SDL.

Agreed. With SDL you can get a loop that copies a 2D array of pixels from main mem to the screen every frame about as fast as possible in a single page of code. If you want to explore software rendering, that's the way to go.

SDL also gives you access to OpenGL, so you can do more with it than just blit textures.

in my gameswithgo.org video series, when we start on graphics, that is how I do it. we implement putpixel, and do some basic 2d rendering by hand. bilinear filtering, alpha blending, etc.