Python graphics library with "QBasic" style pixel functions?

[gomipile]

I'm looking for a simplistic 2d graphics library for Python. All I care about is the ability to define and open a new graphical window, clear that window with a background color, set individual hardware pixels within that window to any color I want, draw filled in squares of a color, and a function that returns the color of any given pixel.

It's important that I can work with individual window pixels that scale and line up perfectly with hardware pixels on the monitor. I'll be working with cellular automata, and I'm sick and tired of having to define umpteen parameters of my square vector pixel stand-ins before I can even start drawing something to the screen that looks vaguely like what I want. Just give me 80s style access to individual pixels please, and let me worry about whether I asked for a window size that's small enough for the OS to fit onto the monitor.

edit: So far, the best I've found are image processing and display libraries. With those, I'd be working with an array of pixel data, and would have to call a rendering function each time I wanted to render the array to the display window. That's slightly less bad than the vector based graphics packages seem, but.... It still seems like way too much faffing about, coding choices, and configuration required before getting to the simplistic results I want.

[gomipile]

I'm not an expert on Python, but it sounds like you basically want to use the physical hardware screen as the memory to store the state of your CA, pixel by pixel, and I am doubtful whether that will end up being simpler than storing an array of cell state data and rendering it to the screen as needed. I think separating the parts of your program that display data from the parts that process data is going to save you a lot of headaches in the long run.

I'm trying to adapt a computer science teaching lesson on cellular automata from the late 80s/early 90s when direct video pixel operations were the norm. Also, doing it that way seems like it should offer less friction to the students setting up the program for themselves. Looking at what would be necessary in tkinter or Pillow, it seems like either I'd have to set everything up for the students and hope they don't mess it up, or write my own package that does what I'm asking for using one of those.

For various pedagogical, administrative, and psychological reasons, I was hoping there would be a named library that "just does" 80s style graphical programming. Any extra work I have to do could also increase the mental workload and frustration of people teaching from this unit in the future, also.

I'm not an expert on Python, but it sounds like you basically want to use the physical hardware screen as the memory to store the state of your CA, pixel by pixel, ...

That would be true on the original 80s and 90s systems I'm obliquely referring to. Technically, though, I want to use the logical screen data inside a created window, not the physical hardware screen.

[halfeye]

I'm trying to adapt a computer science teaching lesson on cellular automata from the late 80s/early 90s when direct video pixel operations were the norm.

...

That would be true on the original 80s and 90s systems I'm obliquely referring to. Technically, though, I want to use the logical screen data inside a created window, not the physical hardware screen.

I dunno about anybody else, but I didn't end up doing it that way in the '80s or '90s. The first micro I owned was a Grundy NewBrain, comical name for a more or less useless system, it had no colour and the only "printer" port it had was an RS 232 variant. My first attempt at Conway's Life did read the screen, but that was horrendously slow. The screen was too big for the available memory as well. I ended up using a set of characters that were present in the system that contained all the states of a two by three part black and white block and having a couple of arrays that represented the state of of the screen, one for the generation being read, the other being written, I think they swapped but it is a long time ago. It was still fairly slow, but only seconds per generation not minutes.

You needed to be able to write to the screen but reading it was typically difficult, I think the NewBrain was unusual in allowing it in Basic.

I never did get anything working in windows in GEM or Windows.

[DavidSh]

What operating system are you using? I think fully portable systems tend to isolate you from the pixel level. If you are using MS Windows, win32gui includes methods for what you want, among a lot of other methods. It includes:

CreateWindow()
SetPixel()
GetPixel()
Rectangle()

But I haven't tested it, so you may require some more boilerplate calls.

[halfeye]

On the other hand, if you were talking about Peeking and Poking, that only worked for graphics if the screen's position in memory was static, and tended to be unavailable in Basics that ran on anything other than micro-computers, for instance Dec System 10 Basic didn't have those commands.

[gomipile]

On the other hand, if you were talking about Peeking and Poking, that only worked for graphics if the screen's position in memory was static, and tended to be unavailable in Basics that ran on anything other than micro-computers, for instance Dec System 10 Basic didn't have those commands.

Is an IBM compatible a micro-computer? AFAIK the definition and usage of the term is fuzzy.

I'm talking about commands that return what's on the screen at a particular pixel or set a pixel. How that is accomplished is abstracted away from the code in the case I was referring to(in the 1980s and 90s past.)

Examples:
https://www.qbasic.net/en/reference/...ement/PSET.htm
https://www.qbasic.net/en/reference/...ent/PRESET.htm
https://www.qbasic.net/en/reference/...tion/POINT.htm

What I'm asking for would be using relative coordinates sandboxed inside a window.

[halfeye]

Is an IBM compatible a micro-computer? AFAIK the definition and usage of the term is fuzzy.

It is fuzzy now. Then, there were mainframes, minis and micros. An original IBM PC or compatible would have been a micro computer. You couldn't run Unix on a micro computer, then. Now you can run Linux on a raspberry pi, I think that any computer or phone with over a GB of ram is probably more powerful than a mainframe was in those days, though there are mainframes or something like them now that are far more powerful than a current PC or Mac.

I'm talking about commands that return what's on the screen at a particular pixel or set a pixel. How that is accomplished is abstracted away from the code in the case I was referring to(in the 1980s and 90s past.)

Examples:
https://www.qbasic.net/en/reference/...ement/PSET.htm
https://www.qbasic.net/en/reference/...ent/PRESET.htm
https://www.qbasic.net/en/reference/...tion/POINT.htm

What I'm asking for would be using relative coordinates sandboxed inside a window.

There were probably hundreds or more sets of commands to do that sort of thing back then, typically different in every different machine or software environment.

I don't know what is current, I'd be really interested to find out. Typically people who make these sorts of things really want you to use their lines, triangles and circles, they seem to dislike letting you or I set or unset particular pixels.