I'm looking to write a quick little fullscreen application for myself to practice writing some basic code (I'll be able to figure out how to get keyboard input and everything I need, most likely), but I want to know how to quickly write a fullscreen application without using DirectX or anything.

And what would I use to write text to it? I can figure out how to do basic 2D graphics (I'm planning on writing pong with this eventually), so I most likely won't need too much help there, but I'm kinda lost as to where to start.
Posted on 2006-06-24 19:49:46 by Bobbias
For Fullscreen get the Desktop Height and Width and then Create a Window using the WS_POPUP Flag without a Titlebar by those sizes.

To write text onto that screen use the Api "TextOut" with a Selected Pen. If you experience flickering then you might want to look into BackBuffers.

Have a look at Iczelions Tutorials Number 2 and 3. 2 teaches you how to create a window, so you only need to modify a couple flags and the size of the window and tutorial 3 teaches you how to write text somewhere onto that window. He uses DrawText, I prefer TextOut. Drawtext is to be used for more advanced text kind of operations. For simple writing text somewhere TextOut should do.

Any questions, just ask.
Posted on 2006-06-24 20:44:39 by JimmyClif
I"m thinking about whether I should dynamically draw my pong paddles, or use resource files in the program (they'll be simple white blocks, not much to them)

And I've been using Iczelions tutorials for this, I just made the basic window, actually, lol. I was just getting lazy since I've been trying all sorts of IDE combos and different things.

In any case, I'll definately be taking advantage of having an actice ASM community to help me along :P

EDIT: How exactly do I get the desktop Height/Width.
I can see that there's a GetDesktopWindow function, but I'm not sure how to get the height and width from the HWND it returns.
Posted on 2006-06-24 22:00:08 by Bobbias
1) GetDesktopWindow
2) GetWindowRect
3) CreateWindow - you use the values returned by GetWindowRect to specify your window's rectangle. Be sure to add WS_POPUP style. Additionally you can add WS_EX_TOPMOST if you like.

Everything else is the same as when you draw to a 'normal' window. You get device contexts, etc, etc.
Posted on 2006-06-25 01:20:01 by ti_mo_n
Thanks, I knew I needed to call GetDesktopWindow, but I havent done enough API work to remember GetWindowRect, I'll follow up with anything else related to this project here, which will probably include a lot of confusion on my ppart, lol.

EDIT: I noticed that there were some conveniant constants available to me
DESKTOPHORZRES and DESKTOPVERTRES

Only problem is that these seem not to be correct (causes what I believe to be a 320x240 window, when I'm runing at 1280x1024).

I can't figure out how to declare a RECT structure to deal with GetWindowRect (I feel like such an idiot for not knowing this), so I opted to use those instead, which has proven that that approach doesn't work.
Posted on 2006-06-25 04:31:17 by Bobbias
DESKTOPHORZRES seems to be the lenght of the virtual screen. (Whatever that may be) So use GetWindowRect instead.

To declare and use a RECT structure check out Iczelions tutorial number 4.

About wondering on how to go along with the pong paddles, well, you could either use a bitmap or draw it using the Rectangle or RoundRect Api.
Posted on 2006-06-25 06:46:49 by JimmyClif
Or you could use this:


  invoke GetSystemMetrics,SM_CXFULLSCREEN
  mov ,eax
  invoke GetSystemMetrics,SM_CYFULLSCREEN
  mov ,eax


then use CreateWindow using Xscreen,Yscreen


Zcoder....
Posted on 2006-06-25 10:37:57 by Zcoder

Or you could use this:


?  invoke GetSystemMetrics,SM_CXFULLSCREEN
?  mov ,eax
?  invoke GetSystemMetrics,SM_CYFULLSCREEN
?  mov ,eax


then use CreateWindow using Xscreen,Yscreen


Zcoder....


This is the width and height in pixels. It may return something like 8000x6000 if you have many desktops, while the active desktop will be 800x600 (and it may start at point [1600, 2400]).
Posted on 2006-06-25 20:26:06 by ti_mo_n
Well, since I've only got one desktop I don't need to worry about that (unless it does something stupid). I think I'll try both ways eventually, since I'll need to learn structs eventually.

In any case, I'll see if this works any better.

I think I'll dynamically draw my paddles and ball first, then use bitmap resources once I get a better handle on asm :P

Thanks fir all the help guys. The reason I abandoned learning ASM before was due to the lack of a community of active ASM coders that I could learn from. (that, and the fact that at one time, I was learning SNES assembly, which has an even smaller following, and requires knowledge of both the SNES processor assembly, and SPC700 assmebly, which is a gigantic pain in the ass (for sound, you write your own sound driver, basically))

All in all, I was NOT up to learning how to code games in SNES ASM, Maybe I'll return once I have x86 ASM down better. Though I'll have to learn a lot about the SNES archetechture, It'll be a lot easier once I know more of what I'm doing. (of course, I still won't have DirectX or anything for graphics and sound :/ So that in itself is going to suck.)

EDIT: those mov instructions don't seem to work, with or without the brackets. Invalid instruction operands...
let's see if i can get the RECT stuff working :/
EDIT2: I've attached my current ASM file, so you guys can take a look and tell me why things aren't working. Note, I completely forget dow to use the SUB instruction, as sad as it is, so the SUB and MOV instructions in my proc are basically guesswork :/ Oh well, I won't keep making the same mistakes very much. I'm fairly good at that.
Attachments:
Posted on 2006-06-25 22:24:55 by Bobbias
Bobbias,

since eax is 32bit register you need to declare XScreen and YScreen as DWORD, like

XScreen dd ?
YScreen dd ?

After changing variable declaration our mov instructions start working. After that see below code to see how to use sub.


;width = right - left
; sub eax,,
lea ebx, DesktopRect
mov eax, RECT.right
sub eax, RECT.left
mov XScreen,eax
;height = bottom - top
; sub eax,,
mov eax, RECT.bottom
sub eax, RECT.top
mov YScreen, eax


Posted on 2006-06-26 04:03:57 by SamiP
Lol, I knew It had to be something relatively simple there with the variables :/

I'd completely forgotten how sub worked, lol, and unfortunately, in the time that I spent looking on documentation, I couldn't find anything that properly ecplained SUB quickly (Which is kinda bad, since I can find documents for the SNES which explain the mnemonics, and all that stuff in a very quick time).

It works. now I gotta change the BG Color to black, text to white, and figure out where my scoreboard will be...
And then comes the fun part of coding the paddle movement.

EDIT:
What do I need to do to make my window's background black.
This is my current code
	mov 	wc.hbrBackground,COLOR_WINDOW

If I change it to this, the background seems to be whatever was under it (effectvely, clear background that doesn't redraw)
	mov 	wc.hbrBackground,Black

And if I or them together, I get this sorta tan color
	mov 	wc.hbrBackground,COLOR_WINDOW or Black
Posted on 2006-06-26 06:32:59 by Bobbias
Bobbias,
Create a solid brush and poke that into the wc.hbrBackground
invoke CreateSolidBrush,0  ; black
mov wc.hbrBackground,eax

Zcoder....
Posted on 2006-06-26 18:36:19 by Zcoder
Thank you SO much, lol. I spent about 2 hours or more working on different ways to render a black background! lol. Of course, they were more or less hacks that would probably slow things down by quite a bit, but I have one question to ask.
Will I have to redraw this somehow, because I plan on double-buffering the window, and displaying my pong paddles on it, and I'd rather know now if they'll leave a trail I need to cover up each frame.
Posted on 2006-06-26 18:45:08 by Bobbias
Sence you said you will be doing double-buffering

Then I would make a black brush to fill the whole area
with black before drawing on it and blitting it to the screen.
other then that you will do just fine.


Zcoder....

Posted on 2006-06-26 19:40:53 by Zcoder
Alright, I'm actually in the middle of writing the code to load the paddle location information and scale the paddles properly (1/10th screen height, by 16 pixels wide (i'm lzy and won't scale this)) and then I'll procede to writing the paint stuff, so thanks for that tip.

I've been working at this for quite some time now, lol.
Posted on 2006-06-26 19:44:07 by Bobbias
I spent about 2 hours or more working on different ways to render a black background!

You could have saved yourself some time by having a look at the first 6 tutorials from Iczelion.

Will I have to redraw this somehow, because I plan on double-buffering the window, and displaying my pong paddles on it, and I'd rather know now if they'll leave a trail I need to cover up each frame.

Yes, you will have to redraw the window for every movement with the paddle or other update.

Please forgive me, but you are missing some essentials here and I wonder if you did not try too take too much of a challenge here.

It seems to me that the board is collectively writing your pong program.

For a quick start on asm opcodes visit Thomas' 'MadWizard' Homepage at www.madwizard.org and read his primer on win32asm. If you're stuck with any opcode (like sub) you can read on up on them over at Randy Hyde's Art of Assembly ( http://webster.cs.ucr.edu/AoA/DOS/AoADosIndex.html ). After that I (still) recommend Iczelion's tutorials to lay down some basics for you.

If I was you I wouldn't worry about a BackBuffer right now, learn how to draw on the window first, learn how to paint text and then learn how to process keyboard and mouse input for the movements of the paddle. A BackBuffer can always be added in the last minute and is an easy cosmetic surgery. All the things just mentionned are explained in great detail in the first 7 Iczelion tutorials. (Add Tut number 25 if you'd like to paint bitmaps)

I believe this thread has run it's course. Do some research and if your stuck with anything in particular don't hesitate to ask.
Posted on 2006-06-26 20:10:44 by JimmyClif
lol, yeah, I realize that I've had way more input from you guys than I should have, but I've gotten keyboard input down (I've made it so escape exits, and can add more easily), I've read tutorial 25, and I found some documents to help with my opcodes, so I shouldn't require much more help unless I bump into some stupid problem or something.

And ASM is not my first language, so I understand a lot of programming concepts, and can probably do the rest myself. I'm not too well versed in the windows API, but I should be able to figure things out. I've worked primarily in VB, and JAVA, and somewhat in C#, but I know C++ as well (it was my first language), so I'm not utterly hopeless.

It's jsut that I've been meaning to learn ASM for quite some time, and this is the first real ASM program I've worked on recently, aside form the Iczelion basic window, which is what turned into this anyway.

If I ever have to deal with something a little more advanced than the real basic game mechanics though, I think I'll end up posting a lot, since I really don't know how to do any of the more advanced mmathematical stuff in ASM (such as trig functions, pi (MAJOR PAIN to calculate, AFAIK, unless you want some ridiculously slow mechanism), etc.)
Posted on 2006-06-26 20:20:05 by Bobbias
I'm glad you're making a lot of progress and I didn't want to scold you for asking for help. You and everyone else deserve any help you can get and your very welcome to post to your hearts content, but also try to help yourself first. :D
Posted on 2006-06-26 20:33:24 by JimmyClif
Hence why I spent 2 hours trying to do just that, :P In any case, I've managed to get the hang of making Macros, Procs, anbd Structs now, and all I gotta do is actully write my code for drawing the paddles, and then I can do collision checking. After that I'll figure out if I want AI, or 2 player pong.
Posted on 2006-06-26 20:37:56 by Bobbias
A very ambitious project. I will follow it with great interest.
Posted on 2006-06-26 20:43:57 by JimmyClif