flat assembler
Message board for the users of flat assembler.

Index > Linux > I just want a window where I can do my stuff. Simplest way?

Goto page 1, 2  Next
Author
Thread Post new topic Reply to topic
axlucas



Joined: 02 May 2014
Posts: 70
Location: Argentina
axlucas 17 Nov 2014, 23:12
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! Smile
Post 17 Nov 2014, 23:12
View user's profile Send private message Reply with quote
JohnFound



Joined: 16 Jun 2003
Posts: 3499
Location: Bulgaria
JohnFound 18 Nov 2014, 05:38
SDL
Post 18 Nov 2014, 05:38
View user's profile Send private message Visit poster's website ICQ Number Reply with quote
pelaillo
Missing in inaction


Joined: 19 Jun 2003
Posts: 878
Location: Colombia
pelaillo 18 Nov 2014, 18:00
gtk_window_new
Post 18 Nov 2014, 18:00
View user's profile Send private message Yahoo Messenger Reply with quote
gens



Joined: 18 Feb 2013
Posts: 161
gens 18 Nov 2014, 19:57
SDL

edit:
i just found out that there is a "delete this post" button
best forum on teh internets
Post 18 Nov 2014, 19:57
View user's profile Send private message Reply with quote
axlucas



Joined: 02 May 2014
Posts: 70
Location: Argentina
axlucas 18 Nov 2014, 20:26
Thank you, guys. I think SDL is not an option, since SDL does not come included with any distro, as far as I know. Is GTK always ready? That is, does the presence of a GUI under GNU/Linux imply GTK is already installed?
Post 18 Nov 2014, 20:26
View user's profile Send private message Reply with quote
JohnFound



Joined: 16 Jun 2003
Posts: 3499
Location: Bulgaria
JohnFound 18 Nov 2014, 20:28
Details:
Check this topic. There is a simple example of SDL use that I adapted to Linux.
Post 18 Nov 2014, 20:28
View user's profile Send private message Visit poster's website ICQ Number Reply with quote
axlucas



Joined: 02 May 2014
Posts: 70
Location: Argentina
axlucas 18 Nov 2014, 21:41
Thank you, John. Yet, this is not what I'm looking for, I'm afraid. In part, because it uses SDL, which is a library that, as far as I know, won't be linked in the program and will become a dependency the user will have to download. Besides, this is a Windows example, although I believe SDL doesn't change much in GNU/Linux.

What I need to know is how I can have X, or GTK (as long as it is always found in GNU/Linux with GUI), open a window for me and give me some address where I can poke my pixels so I can forget about the library for the rest of the code. I would like to use no library, but because I want my program to work in a standard environment, I realise I will have to deal with X or GTK calls. I want to call nothing that will mean the user must download additional packages.

The sticky post at the beginning of the Linux subforum does have some references to X, GTK and QT (I don't want to use QT, because I know it doesn't come with most Linux distros), but when I go to the posts, they refer to dead links, so I see no code to show me how I can get this done. Again, I want something simple. I don't intend to actually use the library, but just have a window open and do the rest myself. I only need mouse coors, buttons and wheel data and an address where I can read/write pixels.
Post 18 Nov 2014, 21:41
View user's profile Send private message Reply with quote
gens



Joined: 18 Feb 2013
Posts: 161
gens 18 Nov 2014, 22:47
you can ship the SDL library with your program or just statically link it in

it is a minimal library, unlike GTK and QT
the guy making it has a brain

you could use X directly with Xlib or the newer, recommended, XCB (or talking directly to the X server via a socket)
but X is not as pretty in places
SDL(2) will work on wayland when it replaces X some day in the future (to get that you would have to use GTK3 or QT5)

i had bookmarked an example of using the kernel framebuffer directly that was interesting, but cant find it now
Post 18 Nov 2014, 22:47
View user's profile Send private message Reply with quote
axlucas



Joined: 02 May 2014
Posts: 70
Location: Argentina
axlucas 18 Nov 2014, 23:04
Yeah Sad It's really sad how we're forced to go through object-oriented abstraction layers. How come! I want to code. I want to know what my program is doing. And I don't like relying on other people's code, like I can't do it myself.
If I go through the framebuffer, what happens if the GUI is running already?
Post 18 Nov 2014, 23:04
View user's profile Send private message Reply with quote
JohnFound



Joined: 16 Jun 2003
Posts: 3499
Location: Bulgaria
JohnFound 19 Nov 2014, 00:43
In the mentioned topic, there is my modification, using FreshLib that compiles for Linux and Windows from the same source.
Post 19 Nov 2014, 00:43
View user's profile Send private message Visit poster's website ICQ Number Reply with quote
gens



Joined: 18 Feb 2013
Posts: 161
gens 19 Nov 2014, 01:25
about the kernel framebuffer, the official documentation
https://www.kernel.org/doc/Documentation/fb/framebuffer.txt

found the example
http://betteros.org/tut/graphics1.php
i can't play with it since i got nvidia binary driver :/

you would get raw input from /dev/input/files
on most distributions these things need permissions set


but SDL is good and fairly light
Ryan Gordon is working on it
and it can even run on a framebuffer

under the xorg server you would have to ask X for a window then set it up, and that's pretty much what SDL does

fun fact; X has fairly optimized drawing functions built in, including stippling
Post 19 Nov 2014, 01:25
View user's profile Send private message Reply with quote
axlucas



Joined: 02 May 2014
Posts: 70
Location: Argentina
axlucas 19 Nov 2014, 03:39
Thank you, John. I know SDL is good software. I've just been taking a look at FreshLib too Smile I do appreciate it. Only that sometimes, instead of looking for power, I just want simplicity and it's so hard to find it nowadays. Using other people's libraries is something I've always avoided. Now I'm trying to "dodge" the many bloated abstraction layers that exist on modern systems. I do like what these good libraries do. I just would like it to be an option to use libraries and not something mandatory. I'll read more about FreshLib Smile

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]
Post 19 Nov 2014, 03:39
View user's profile Send private message Reply with quote
pelaillo
Missing in inaction


Joined: 19 Jun 2003
Posts: 878
Location: Colombia
pelaillo 19 Nov 2014, 13:19
axlucas, using SDL is the best option. If you are planning to distribute your program, any package manager will take care of managing library dependencies, in this case, SDL. This process works very well in most linux distributions.

I have suggested the use of GTK because it is already available on your distro and you are going to rely on very few calls for window management and mouse tracking. But if you use SDL and FreshLib, you will have the added bonus of reusing the same source for both Windows and Linux with a very little overhead.
Post 19 Nov 2014, 13:19
View user's profile Send private message Yahoo Messenger Reply with quote
gens



Joined: 18 Feb 2013
Posts: 161
gens 19 Nov 2014, 13:34
axlucas wrote:
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]


well...
it is a simple thing
more or less the simplest way of getting graphics on the screen in linux in that you just mmap a file and write to it
technically simple that is, SDL would be a bit simpler from the API standpoint (especially compared to X)

afaik X (the GUI) does not use the framebuffer although i have read somewhere that it does
even if it does there are more then one of them (4 usually), so you can use any of the other ones

using the kernel framebuffer won't show under X, thats for sure
you can get to the... terminals, buffers, whatever they are called by pressing ctrl+alt+f1-12
when you are out of X you can use alt+left/right to cycle through them quickly (or alt+f's)

a quick test if it works would be dumping random data to the framebuffer
cat /dev/urandom > /dev/fb0
then looking if one of them is sparkly Smile
(/dev/fb1 would be another framebuffer)

note that this needs the fbdev module loaded and OSS drivers for the gpu


idk who he is, he posted on linuxquestions.org
i guess just another guy that likes low level toys Smile
Post 19 Nov 2014, 13:34
View user's profile Send private message Reply with quote
axlucas



Joined: 02 May 2014
Posts: 70
Location: Argentina
axlucas 19 Nov 2014, 22:41
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
    
Post 19 Nov 2014, 22:41
View user's profile Send private message Reply with quote
Matrix



Joined: 04 Sep 2004
Posts: 1166
Location: Overflow
Matrix 21 Nov 2014, 00:34
axlucas wrote:
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
    


Well you can read sdl's source and grab what you need, this would be an instant solution
Post 21 Nov 2014, 00:34
View user's profile Send private message Visit poster's website Reply with quote
Matrix



Joined: 04 Sep 2004
Posts: 1166
Location: Overflow
Matrix 21 Nov 2014, 01:08
axlucas wrote:
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! Smile

The simplest way to make a window is described here:
http://rosettacode.org/wiki/Window_creation/X11
Post 21 Nov 2014, 01:08
View user's profile Send private message Visit poster's website Reply with quote
sleepsleep



Joined: 05 Oct 2006
Posts: 12870
Location: ˛                             ⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣Posts: 0010456
sleepsleep 21 Nov 2014, 17:57
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.
Post 21 Nov 2014, 17:57
View user's profile Send private message Reply with quote
Matrix



Joined: 04 Sep 2004
Posts: 1166
Location: Overflow
Matrix 21 Nov 2014, 18:55
sleepsleep wrote:
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.


Basically what we want is to use a framebuffer, in my previous post i linked x11 method, since we are using x11, we have no choice but to use that for displaying a window.
NO SDL is needed for basic window creation and window drawing.

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? Wink

Code:
// 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;
}
    


A Brief intro to X11 Programming
Post 21 Nov 2014, 18:55
View user's profile Send private message Visit poster's website Reply with quote
sleepsleep



Joined: 05 Oct 2006
Posts: 12870
Location: ˛                             ⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣Posts: 0010456
sleepsleep 21 Nov 2014, 23:03
Matrix wrote:

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?


thanks for the X11,
was thinking SDL could be cross platforms,
X over ssh might be useful too, X ming x server,

so, all X GUI applications run inside main server, all the windows client just ssh over to use,
Post 21 Nov 2014, 23:03
View user's profile Send private message Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  
Goto page 1, 2  Next

< Last Thread | Next Thread >
Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Copyright © 1999-2024, Tomasz Grysztar. Also on GitHub, YouTube.

Website powered by rwasa.