Gens, thank you too. The framebuffer is very interesting, although I see it is no simple thing. For what I read, though, I understand that, if a GUI is already running, my framebuffer program won't run, or at least, the output won't be seen. Am I right? Yet, it's great because it means I can do graphics while in console mode. I'll take a closer look. By the way, I hadn't been to betterOS.org. I like the philosophy of this site. Who is this guy?[/code]

push width
push height
call create_window
pop buffer_address
.
.
(read and write in the buffer, use the mouse, run the program in that only window, do my own drawing not calling any other function in any library, but only within my program)
.
.
push buffer_address
call delete_window
push 0
call exit
    

I've been taking a closer look. It's true, the framebuffer is really simple to interface. At first, I thought it was complicated, because I saw the code was so long and full of structures, but then, as I read slowly, I saw that most of the code is not about the framebuffer, but about other options. Thank you. I do like this. I would like to use it to be able to work outside the GUI, DOS style, and only use graphics when really necessary.

The problems are, of course, that this won't allow me to make a "standard" program than anybody can easily use in their Linux, because I can't create a window like I said first. Also, I don't know how to access the mouse while not in X. Maybe the best solution available for me would be to create a small program that does this with XLib, which is standard, and then link that to my assembly programs, so I only have to suffer once.

Again, I agree that SDL is great, efficient and multiplatform and that is very easy to get. yet, this is not what I'm looking now. The reasons are: first, SDL is a high level interface and it's a waste of resources to use it only to open a window and get a pointer to the buffer, when I can do the same thing with something that's already installed in the system. Second, easy or not to install, SDL makes my application internet-dependent, because the user won't be able to get it copied from somebody else in a USB drive and just run it: they will have to download something from the internet. It would also be time-dependent, because if one day SDL changes or becomes obsolete because something new and more powerful comes up, it will be very hard to get my program running.

In a sentence: I'm not looking for power; I'm looking for independence. At least this time, in this particular post.

What I would like, this time, is something that allows me to write programs like this:

Code:

push width
push height
call create_window
pop buffer_address
.
.
(read and write in the buffer, use the mouse, run the program in that only window, do my own drawing not calling any other function in any library, but only within my program)
.
.
push buffer_address
call delete_window
push 0
call exit
    

Hi, guys. I would like to find the simplest way that I could use in FASM to create a program that:

* Starts up by opening one window in the GUI, that can be moved and closed
* Has direct linear access to a buffer where I can put and read pixels in and from the window
* Can read mouse position, buttons and wheel status
* Has the minimum possible dependencies and any dependencies it has are guaranteed or almost guaranteed to be found on any Linux distro just after install

On the other hand:

* I'm not interested in opening any more windows. Only one for the whole time the program is running
* The window doesn't have to be resizable or transparent or have any additional features. If possible, a standard GUI window, with no menus and that I don't have to program myself to be moved would be perfect, but I'd like to avoid unnecessary libraries
* I am not going to be using any buttons or other GUI objects. I'm planning to draw everything myself
* I don't need a specific colour mode. Just the one being used by the system, as long as I can know what it is. Then I can emulate whatever I want myself on top of it

In other words: I would like my program to be as much assembly and as little non-assembly as possible, yet be standard and manage graphics. What would be best? Any link to code I can see that accomplishes this?

Thank you all so much!

In a sentence: I'm not looking for power; I'm looking for independence. At least this time, in this particular post.

https://www.libsdl.org/download-1.2.php
http://www.libsdl.org/projects/

libsdl historic version and from there maybe?

Quote:

In a sentence: I'm not looking for power; I'm looking for independence. At least this time, in this particular post.

i like this, and with same kinda mindset too, let me know if you decided spending more hours on this is worth it.

// xlib0.c
// compile with:
// gcc -o xlib0 xlib0.c -L/usr/X11R6/lib -lX11
#include <X11/Xlib.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
 
int main(void) {
   Display *d;
   Window w;
   XEvent e;
   char *msg = "Hello, World!";
   int s;
 
   d = XOpenDisplay(NULL);
   if (d == NULL) {
      fprintf(stderr, "Cannot open display\n");
      exit(1);
   }
 
   s = DefaultScreen(d);
   w = XCreateSimpleWindow(d, RootWindow(d, s), 10, 10, 100, 100, 1,
                           BlackPixel(d, s), WhitePixel(d, s));
   XSelectInput(d, w, ExposureMask | KeyPressMask);
   XMapWindow(d, w);
 
   while (1) {
      XNextEvent(d, &e);
      if (e.type == Expose) {
         XFillRectangle(d, w, DefaultGC(d, s), 20, 20, 10, 10);
         XDrawString(d, w, DefaultGC(d, s), 10, 50, msg, strlen(msg));
      }
      if (e.type == KeyPress)
         break;
   }
 
   XCloseDisplay(d);
   return 0;
}
    

If you would want to go lower you don't need x11, you just speak to the video card directly.
Do you even need GNU-Linux then?