Index
> DOS > Question: How to do GUI in mode 13h?Goto page 1, 2 Next |
| Author |
|
|
bitRAKE 10 Nov 2010, 02:35
Some history...
http://www.atarimagazines.com/v4n9/tosroadmap.html Of course, nothing is preventing you from doing something unique in terms of look-and-feel, but some basic things will need to happen: There will be structures which define the GUI objects. When some action takes place these structures are searched to determine which object is being acted upon. The display will need to be drawn in layers (bottom-up). The mouse routines could cache the data underneath the cursor. Object IDs, or message passing is a further abstraction which isn't really required. For example, the ID could be just position in the tree of objects, and each object could have just a single action. The complexity is up to you. |
|||
10 Nov 2010, 02:35 |
|
|
revolution 10 Nov 2010, 06:09
One thing to note is that whether you use mode 0x13, or other graphics modes, that should not affect the way in which you design the GUI. Let the OS drivers handle colour depth conversions and resolution requirements for the current graphics mode.
|
|||
|
10 Nov 2010, 06:09 |
|
|
edfed 10 Nov 2010, 14:55
a gui is a tree.
|
|||
|
10 Nov 2010, 14:55 |
|
|
adroit 11 Nov 2010, 00:54
Thanks!
I got the basic concept concept of GUI now. So: How are these objects defined in a structure? How are can there be a strata (layers)? Do you use multiple segments? Quote: Object IDs, or message passing is a further abstraction which isn't really required. For example, the ID could be just position in the tree of objects, and each object could have just a single action. The complexity is up to you. What is a tree of objects? How can it be defined? edfed, how so? [yea I know, I ask alot of questions] |
|||
|
11 Nov 2010, 00:54 |
|
|
revolution 11 Nov 2010, 01:01
MeshNix: You can use any data structures you want. Whatever suits your purpose. Just think of it like a small database storing the object's details.
It you want to use trees then there are many many available tree structure formats. I'm sure a quick search will give oodles of links. |
|||
|
11 Nov 2010, 01:01 |
|
|
rugxulo 12 Nov 2010, 19:34
http://www3.telus.net/alexander_russell/course/introduction.htm
http://ftp.lanet.lv/ftp/mirror/x2ftp/msdos/programming/source/00index.html http://ftp.lanet.lv/ftp/mirror/x2ftp/msdos/programming/gpe/00index.html http://ftp.lanet.lv/ftp/mirror/x2ftp/msdos/programming/gamesrc/00index.html BTW, I converted the (TASM) PSR Invaders game to FASM. Both Dex and Octavio truly ported it to their OSes (MiniDos, OctaOS). Just in case you want a real DOS / VGA example. |
|||
|
12 Nov 2010, 19:34 |
|
|
DOS386 17 Nov 2010, 01:57
You might want to look at VESA because you soon will find out that 320x200x8bpp is a bit limited
About the mouse arrow, you have to either backup the pixels covered, or keep a backbuffer without the arrow and "patch-in" the arrow when updating the VRAM (FreeBASIC does this way). Also, you should NOT update the screen from the mouse interrupt (this a a common fault  ), in the mouse interrupt just update the variables and deal with the screen in a separate screen-related interrupt.
The DOS mouse driver could handle the arrow for you in some cases but this is a bad idea - don't try to use this "feature", see above. Also, avoid VRAM reading, this usually "works" but is slow (can be extremely slow). About clicking, you will get the mouse coordinates at the time of click, then you search your GUI structures to find out what is supposed to happen. _________________ Bug Nr.: 12345 Title: Hello World program compiles to 100 KB !!! Status: Closed: NOT a Bug |
|||
|
17 Nov 2010, 01:57 |
|
|
adroit 17 Nov 2010, 03:01
[thanks guys]
revolution, I researched some tree structures, but don't know how to implement them in assembly. rugxulo, really helpful stuff! Thanks, man. Also, nice work on INV2FASM. DOS386, VESA? It's a bit advance and complicated for me, I think. Is it highly recommended that I should use it, or what? GUI structures? What are they? How are they implemented? |
|||
|
17 Nov 2010, 03:01 |
|
|
DOS386 21 Dec 2010, 14:24
> VESA? It's a bit advance and complicated for me, I think.
> Is it highly recommended that I should use it, or what? YES it is  (for now or at least for later). With 320x200 you will soon find out that pixels are HUUUUUUUUUUUUUUUGE and and screen is ridiculously "small", you barely find space to place 40 characters in a line.
> GUI structures? What are they? For example a "Do B.S. now" button as rectangle from 100,170 to 160,190. There may be more buttons and clickable areas. Check if the arrow is inside any of them at occasion of every click. _________________ Bug Nr.: 12345 Title: Hello World program compiles to 100 KB !!! Status: Closed: NOT a Bug |
|||
|
21 Dec 2010, 14:24 |
|
|
adroit 02 Jan 2011, 02:32
I still don't get the tree concept!. But I pretty much have an idea. Let's say we have the rectangle 100,170 to 160,190.
rectangle dimensions:
height = 20 x1,y1 = 100,170 x2,y2 = 160,190 So as long as the cursor is within the parameters of 100,170 and 160,190 then the action assigned to the button can be executed. How do I check? Will the tree have this information? Do I can every 60 pixels on each for 20 lines to see if the cursor is there? I think I could have a structure that could have certain information on that object. Probably, the structure could hold information such as, height, width, etc.
.x .y .width .height .area ends What is I have something like a window? About VESA. I checked out a few stuff on VESA and I realized that it isn't as simple as VGA (mode 13h). To put a pixel is very difficult unlike the simple, AH=0Ch/Int 10h. I don't know where to find useful and sufficient information on VESA. Can someone give me some links? Thanks! ------------- Yea your right, VGA 320x200 pixels are HUGE!!! I recently made a routine to DrawText in VGA and it doesn't look so pretty. So I guess VESA is the only option left. Does it work in DOS? (meaning, if I enter VESA mode in XP, would it work?) [quote=edfed]a gui is a tree[/quote] Huh? |
|||
|
02 Jan 2011, 02:32 |
|
|
edfed 02 Jan 2011, 02:54
a gui is a tree.
the root is the screen the first window is a node this node will lead to a hierarchical object list. and every object will be accessible by path. for example, imagine the text here, named Txt1, inside the window firefox. then, the path can be: screen/applications/firefox/workspace/html file/edfed post 2/Txt1 the adress text in firefox can be accessible by another path: screen/applications/firefox/menubar/adressbar/adress text. do you see more what i mean by gui is a tree? |
|||
|
02 Jan 2011, 02:54 |
|
|
adroit 02 Jan 2011, 03:11
Oooooh!! I kind of understand, but I think I am getting a bit to technical with this stuff. So, a window branches from the screen, and the objects branch from a window and so on...
[I say your Tetros game you made and it was pretty amazing. I like how you make the virtual screen] |
|||
|
02 Jan 2011, 03:11 |
|
|
edfed 02 Jan 2011, 03:43
it is made using fool.
fool is the name of the lib i develloped to do "easy" graphix programming with fasm. it was first just for graphic purpose, only graphic primitive were supported, but after, i realised that even non graphics objects can be considered as graphic items. like read a file, crypt a file, and even call a function, are items. everything can be represented by a data structure, and represented by a tree. even a purelly sequential asm code can be represented by a tree. jcc is to be a fork, xlat to be a node, etc... it depends on what you decided before to code. items in fool are just data structures with the first data to be the type of the item, for example, box, line, dosfile, disk, etc... the following datas are the arguments for the function pointed to by the first data. Code: item0: dd function,arg1,arg2,arg3 box1: dd box,x,y,xl,yl,color as you can see, there are no asm instructions, only datas. then, it is easy to imagine an object type to contain other objects. Code: item1: dd node,size,item0,item2,item3 then, you have all the ingredients to build a gui. |
|||
|
02 Jan 2011, 03:43 |
|
|
adroit 03 Jan 2011, 02:27
hmm.. interesting!! That's some brilliant piece of coding! But how does FOOL execute the function if it's just data? I'm just curious.
OK, since a data structure can be almost anything, I assume, then this gave me an idea. My idea: what if I use a structure to hold certain information? for example: a structure that holds a window node's information, such as, window id, width, height, etc. Code: struct wNone ; Window Node id dd ? ; window id x1 dw? ; left y1 dw ? ; top x2 dw ? ; right y2 dw ? ; bottom width dw ? ; window width height dw ? ; window height title rb 128 ; window caption cache rb 64000 ; cache the screen data beneath the window ends |
|||
|
03 Jan 2011, 02:27 |
|
|
edfed 03 Jan 2011, 16:54
hehe, thats here the problem with your interpretation:
Code: struct wNone ; Window Node id dd ? ; window id ;no no no, this is not the id of the window x1 dw? ; left y1 dw ? ; top x2 dw ? ; right y2 dw ? ; bottom width dw ? ; window width height dw ? ; window height title rb 128 ; window caption cache rb 64000 ; cache the screen data beneath the window ends the first data is not an id about the item, but the id of the fucntion needed to execute the item. then, it will look like this: Code: struct wNone ; Window Node call dd ? ; funtions id to call for this item x1 dw? ; left y1 dw ? ; top x2 dw ? ; right y2 dw ? ; bottom width dw ? ; window width height dw ? ; window height title rb 128 ; window caption cache rb 64000 ; cache the screen data beneath the window ends the id of the item is its adress, only its adress, and is not into the data structure. then, to execute, you take the first data, and use it as a pointer to a function, and call it. of course, you need to pass a parameter to the function, this parameter is the pointer to the item. in fool, i use esi for the current item, and as graphic needs relative position, edi is used as parent item. then, each time a graphic item is executed, the X and Y values from parent will be added to x,y of current, and on return, x and y of current are restored. and note, X2, Y2 are bad design. it is more efficient for the graphic items to have X,Y, XL and YL. L for lengh. then, you have the start coordinates, and the count of pixels. of course, a windows just needs: required: coordinates: x,y,xl,yl optional: title bar: icon, title, system buttons... menu bar: menu items, adress bar... then, you see that everything is optional. even coordinates are optional because a window can be hidden, or non graphic. then, all is tree. if you make the node function, you will be able to support trees. Code: node: .call=0 .size=4 .data=8 ;edi is the parent item ;esi is the current item mov eax,[esi+.size] shr eax,2 dec eax jl .end .next: push eax esi mov esi,[esi+eax*4+.data] call caller ;will call function pointed to by [esi+0] pop esi eax dec eax jnl .next .end: ret to use it, just see that: Code: mov esi,main call caller ... main dd node,@f-$-4,item1,item2,item3 @@ item1 dd node,@f-$-4,item2,item3 @@: item2 dd node,@f-$-4,item3 @@: item3 dd putpixel,0,10,1,2,color ;put a pixel at 0,10, 1 pixel large, 2 pixels high. putpixel: ret ;do nothing because it is just an example if you want, you can join me in the dev of fool, i will be happy to teach you first, and work with you after.  |
|||
|
03 Jan 2011, 16:54 |
|
|
edfed 04 Jan 2011, 01:45
about the desktop, i have some idea.
i give it here because fasm rocks. then, let code using fasm. Code: desk dd @f @@: Node @f,\ drives,\;comment this line for windows XP test. .pal,.vga @@: Asm movdw,desk,.entry .vga: dd f.vga .pal: Asm palette.flashy ;Asm palette.default ;Asm palette.grey .vsync: dd f.refresh,White,pal.user .entry: Gnode 0,0,320,200,\ .vsync,\ showfps,\ a.hlt,\ mouse.item,\ popup,\ prompt,\ .top,\ exit.key,\ zoom,\ tooglemouse .top: ; the idea is here... Gnode 0,0,320,200,@f @@: ;the user application start here. basically, the desktop is the board of a desk, in real worl i mean. then, the equipment of the desk is mouse item, screen item, chair, lamp, distance (zoom) and of course, the top, the board where we put the applications. then, the idea is just to load an application right after this code, and it will work. if there is no application (dd 0), then, do nothing, only the desk elements will be active, mouse, fps monitor, hotkeys, etc... it works then, it can't be so bad. |
|||
|
04 Jan 2011, 01:45 |
|
|
adroit 06 Jan 2011, 03:35
The X,Y,XL,YL idea is very logical. I agree. So each time a window it is to be redrawn, these values are checked, or so i assume. But i think width & height do the same thing. I use he width and height arguments in my DrawRect functions, but just not in a structure.
edfed, Quote: the first data is not an id about the item, but the id of the fucntion needed to execute the item. But the FOOL syntax and program structure is a bit complex--I don't understand. I still don't get it up to now  . But I think
That desktop idea is incredible, man. It will come in handy for me later in my library. Thanks! Um about this code: Code: mov esi,main call caller ... main dd node,@f-$-4,item1,item2,item3 @@ item1 dd node,@f-$-4,item2,item3 @@: item2 dd node,@f-$-4,item3 @@: item3 dd putpixel,0,10,1,2,color ;put a pixel at 0,10, 1 pixel large, 2 pixels high. putpixel: ret ;do nothing because it is just an example Oh so, main has all the points to each item, and it is passed it SI, and caller calls each item in main? What's the difference between a Gnode and a Node? Does a Gnode define where a sprite should be one screen? I am so confused. How is the tree structured using Gnode & Node? You should write a Technical Document and a Programmer's Guide for FOOL. _________________ Quick Idea: I have an idea to use message passing in my library. The mouse and keyboard will generate events. Events generate messages and these messages will be passed to the system to handle. The main objects of the GUI system are: the Screen, Keyboard and the Mouse. To maintain objects on the screen a window will be used. A window is a rectangular region of the screen. A window is tangible to the mouse. And each window has a function assigned to it. There are four different window types: main window, child window and control window. A main window is the window used by the application, and a child window is a child of the main window. Control windows are different. A control windows can branch from both main and dialog windows. The purpose of a control window will be to hold texts, sprites or buttons on the screen. A control window's function is user-defined. The window can be a assigned a function whenever it is clicked by the mouse or a key is pressed on the keyboard. Other windows such as a main or dialog window are automatically assigned a function so that when the mouse clicks it, the grad-window function is called. This is just a random idea of mine. But i would like to use the structure of FOOL. _________________ edfed wrote: if you want, you can join me in the dev of fool, i will be happy to teach you first, and work with you after. I would more than be happy to. Just say when and where. |
|||
|
06 Jan 2011, 03:35 |
|
|
me239 06 Jan 2011, 06:11
I reccomend that you use mode 12h. It may have only 16 colors, but it's fast and 640*480 I believe.
|
|||
|
06 Jan 2011, 06:11 |
|
|
edfed 06 Jan 2011, 08:29
the graphic mode is something like just a layer, and this layer is putpixel, just change putpixel, and you have changed the screen resolution
the choice of the resolution to dev OS in ASM is just a compromised choice, do you prefer big resolution? or simple way to manage? don't forget that OS in devellopment stages don't need at all to support a lot of modes, only one is required, the favourite of the coder. after, when it comes ot be something interesting for more people, then, it is time to hack the VESA and of course, try to write a driver for your GPU if you have the doc. meshnix, about the join, when you want, i am almost always here. about the fool syntax understanding, i think i will show you first the embryo of fool, and then, you will understand why it is like that now. about Gnode, it is for Graphic Node, because instead of being only a list, it is a list, with the 2D field, exactlly as would be the structure for a rectangle (here is box, because only 3 letters)
PM |
|||
|
06 Jan 2011, 08:29 |
|
| Goto page 1, 2 Next < Last Thread | Next Thread > |
Forum Rules:
|