• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.

Archived

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

Rah

Alt-Tabbing

10 posts in this topic

Hi all, I realise this topic has come up numerous times before (I''ve searched..) but nothing quite fits my problem. At the moment, I''m listening out for a WM_ACTIATE msg in my callback procedure, and setting a boolean variable to indicate whether my app has focus or not. Then, I have a main() loop which I call if, and only if, my variable indicates we''re currently active. Ok... my problem is that this only works 1 in 10 times, if that. I''m guessing my problem is that my app is losing focus whilst within main() thus crashing out before realising it''s not active (when it gets to its callback func). Basically what I need is an elegant solution to fix this... asuming my guess is right. I''ve narrowed my flipping() function to be the one that crashes ddraw fully, with all prior blitting/locking functions simply returning DDERR_SURFACELOST. I tried calling my own RestoreAllSurfaces() function before calling flip() so I could see if we had focus (ie. checks if focus is lost, then checks to see if it can restore... if it can''t we must of lost focus). This works 9/10 times, but occasionly still hangs my system. Again, I''m guessing we lose focus inbetween this check, and the actual flip() call. Anyway, I''ve rambled enough and its probably all crap so I''ll stop Any general pointers etc. greatly appreciated, Thanks, -- Rah
0

Share this post


Link to post
Share on other sites
For full screen projects, I do something very similar to what you describe, however, I check WM_ACTIVATEAPP. I set the flag when I receive this message, and then I check the flag in two places... My message loop (prior to doing the next game update) and before I do any actual updating of the screen (before I try to flip) or attempt to create surfaces in vram.




Mark Fassett
Laughing Dragon Entertainment
http:\\www.laughing-dragon.com
0

Share this post


Link to post
Share on other sites
as i understand from what you are telling, you imply that you would receive a message while inside your main loop.
i don''t think that is possible because you have to call getmessage() to actually receive the message first...
so i think your problem lays in some other part of your app...
btw i am using the same technique and it works fine for me...
what parameter of the WM_ACTIVE message do you use for your active check? there are two and one wouldn''t do for my check
0

Share this post


Link to post
Share on other sites
Hi,

Basically what I thought was happening was that my app was losing focus, before I recieved the message (whilst in the main() loop) but I realise this was wrong now...

I fixed it by using WM_ACTIVEAPP as Mark suggested. This seems to work fine now (which is good )

Thanks for your input all,

--
Rah
0

Share this post


Link to post
Share on other sites
Hi again

Following on from before, I now have a working routine.
One thing though... On my p200mmx, 4mb matrox mystique, I just can't get the damn thing to lose its surface data (the surfaces become 'lost' when alt-tabbing, but don't seem to lose their data). I've tried loading other games whilst my app is out of focus etc. to try and lose the images, but it just won't let em' go

Is this normal...? On trying on my other machine, p400, 8mb ati, it loses its data ok.

I'm creating two 800x600 surfaces (primary, backbuffer) in video ram, and also an 800x600 offscreen surface (also in vid ram), all in 16bit.

Could it be that DX is placing my offscreen surface into sysram without telling me? All load functions return no errors to suggest this however.

Any ideas?

--
Rah

Edited by - Rah on 2/21/00 6:41:20 PM
0

Share this post


Link to post
Share on other sites
If you really want to know where the surfaces are, you can check the surface description (it''s in the DDSCAPS or DDSCAPS2 structure (depending on which DX version you''re using) to figure it out.

You may want to check and see if your offscreen surface is in system ram (I''m assuming this is the one where the data still is). If it is getting put there, it means you didn''t lose that surface (you can''t lose system ram surfaces), you lost one of your other surfaces.

I''m interested in knowing how you''re finding out that the data is still valid? Is it causing a problem?

Mark Fassett
Laughing Dragon Entertainment
http:\\www.laughing-dragon.com
0

Share this post


Link to post
Share on other sites
Hi Mark,

The reason I know the data I loaded onto the surface is still valid (after a RestoreAllSurfaces()) is basically because I can see it... ie. I blit it. On my other computer this just appears as a black square (data has been lost).

It's not causing a problem as such, I'm just interested in knowing why and making sure my routines work correctly.

Thanks for the tip with DDSCAPS, I'll have a play around with that in a sec. However, I'm pretty sure it (my offscreen surface) is being created in video ram as I get around 85fps (on p200, 4mb old gfx card). I could surely not achieve blitting an 800x600x16 surface from system->vid ram at this speed. When explicitly setting my program to create the offscreen surface in system ram, I get around 24fps... a more realistic figure.

Anyway, I'll see what I can figure out. Like I said, it's not a problem, I'm just interested to know why this is happening.

Thanks

--
Rah

Edited by - Rah on 2/22/00 9:08:55 AM
0

Share this post


Link to post
Share on other sites
Hi,

As an update, my program is definitely creating my offscreen surface in video ram (check with GetCaps()), yet doesn''t seem to lose its surface contents. Weird.

--
Rah
0

Share this post


Link to post
Share on other sites
And I wouldn''t rely on it being there either... The ATI driver might be cleaning it up... the Matrox driver might not. In any case, if you''ve been told it''s been lost, you should restore it anyway, regardless of whether the data is still there. Using data you no longer own is a good way to get yourself in trouble (although I''m sure you know that

Mark Fassett
Laughing Dragon Entertainment
http:\\www.laughing-dragon.com
0

Share this post


Link to post
Share on other sites
Hi all,

Ok, thanks for all your replies. Has been very helpful. I''ll definitely continure restoring/reloading all my surfaces... it''s just nice to know why that was happening.

Thanks again

--
Rah
0

Share this post


Link to post
Share on other sites