Archived

This topic is now archived and is closed to further replies.

HELP!! My screen shows garbage!!!!

This topic is 6073 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I am writing a small demo of a bouncing fireball in Turbo C++ 3 (MS-DOS !!). When I run it in the IDE it works fine, but when I run it in Windows (or DOS for that matter), it show nothing but garbage on the screen!!!! Could it have something to do with my GetPixel function? The thing works, but the compiler warns me that it should return a value ?!?!? If you want the source, you can download it at http://www16.brinkster.com/mainforze/mfz.c Please help!! I''m a newbie when it comes to C++!!! Thanks in advance, MainForze

Share this post


Link to post
Share on other sites
I am not too sure about your code but the GetPixel function should return a value, but it doesn''t. You see, in your code you have said something like this:

GP1=GetPixel(.....);

but your function GetPixel() does not have the statement:
return ;

like it should. Your function is meant to return and unsigned char but all it does it perform something in assembler then exits with returning anything. Try putting a return statement in the function code and see what happens

Dark Star

Share this post


Link to post
Share on other sites
Here''s what I think your problem is. First of all, in the most case, your GetPixel should have ret al. Or you could push al on the stack and then simply type ret. Anyhow, that''s another story. Also, in order for your program to store the old data from some of the registers as it needs them, the first line of any ASM function should always be PUSHALL and the last line, always a POPALL ( ie, I think those were function I coded though but basicly, they push all the basic registers on the stack and popall, pops them all back. If you''re not sure what I''m saying, I would recommend a getting a good book. Nerver forget the push and pop. Cost me to many lost hours of sleep to get a project that I was working on to work when I was a tad bit younger. Anyhow, those are my points of view. I think this SHOULD help. Not sure though but it should get your project up and running. I also have one last comment, you should put all of your asm into a seperate file and include it in the project. It''s easier and gives better control over ASM as inline ASM doesn''t understand all the commands as it''s compiled by the C++ compiler where as a seperate file is compiled by the asm compiler that will be specified in your settings. So it creates a true .obj file and then links it with your other .obj files to create your exe... Again, these are only my views but take it from someone who did those mistakes also.



"And that''s the bottom line cause I said so!"

Cyberdrek
Headhunter Soft
A division of DLC Multimedia

Resist Windows XP''s Invasive Production Activation Technology!

Share this post


Link to post
Share on other sites
Hey I''m a newbie too, but I figured I would throw in my 2 Cents.
First of all, I would remove the asm till it work all the time.
That will at least narrow things down a little, put in your return statement. I would make sure that your code initalizes everything. Your debugger may be initalizing variables for you then when you run the program from the command line the debugger isn''t there anymore.
Thats all I have to say about that.



Jason Mickela
ICQ : 873518
E-Mail: jmickela@pacbell.net
------------------------------
"Evil attacks from all sides
but the greatest evil attacks
from within." Me
------------------------------

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
I''m not sure it would matter if it didn''t return a value as this is what the asm code does. AX is used as the return register. (AL,AX,DS:AX).The only problem would be if the compiler inserts some "cleanup" cope at the end of the proc which alters the al register.

There is another possibility, but this seems unlikely.
If your program is running in protected mode (virtual 86 or whatever its called), your program may not have priviledge to access the ports that u use to alter the palette. However, I would expect this to generate some protection fault rather than ignore it and many other DOS programs use mode 0x13 and change the palette as you have with no problems.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
oops i thort you said it worked in dos but not windows ignore above

Share this post


Link to post
Share on other sites
I think that most compilers always pushes and pops some stuff when going in and out of blocks and you can not always predict where, also when going in and out of inline assembly, (it might also make diffrent code depending on your settings (debug or release) ).
A solution would be to do something similar to the thing you do
with xCoor and yCoor...

LIKE THIS:

unsigned char GetPixel(.....){
unsigned char retval;
asm{
mov ax, 0xa000
mov es,ax
mov bx,[xCoor]
mov dx,[yCoor]
mov di,bx
mov bx,dx
shl dx,0x8
shl bx,0x6
add dx,bx
add di,dx
mov [retval],es:[di]
}
return retval;
}


Although I guess you could do it easier and probably more optimised with pointer arithmetics

unsigned char GetPixel(int xcoor, int ycoor)(
{
// assume screenpointer is a valid pointer to 0xA000:0000
return *(screenpointer+yCoor<<8+yCoor<<6+xCoor);
}

Share this post


Link to post
Share on other sites
Thanks you guys for all the replies!!! I managed to straighten it out before I had the chamce to check back here, but thanks anyway!! WOW, I really LOVE this messageboard!! All my posts were replied within a day!! Hell, once I had I reply within a few minutes!!!! This thing is really great!!!

Share this post


Link to post
Share on other sites