• 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.


  • Content count

  • Joined

  • Last visited

Community Reputation

567 Good

About yadango

  • Rank
    Advanced Member
  1. [quote name='Postie' timestamp='1348799916' post='4984568'] I'm struggling to follow your reasoning as to why you have to look backwards to determine the cost of the path going forwards. If your weights are done correctly, getting to node D includes the cost of getting to any of the previous nodes that made up the path. Unless your movement along the terrain can cause a landslide that affects the path ahead I don't follow your line of thinking. [/quote] Correct. Yeah, if say using squared RMS (square of euclidean distance), you really pay for doing large uphills in the first place, so even something simple like that should take care of things like the one large hill + one small hill is worse than two medium size hills of the same distance problem. I was just trying to extend the problem in a different way to see where I could go with it he he he. So in general, after reading the research on these types of problems, I've accepted that you should never break Bellman's Principle unless you absolutely have to. It's fun stuff though... there are some really interesting problems that break Bellman's Principle (mainly time-based things like traffic and music performance).
  2. Thanks alvaro, Thanks to you guys I think I found a journal article on the topic: "Finding the Shortest Path in Dynamic Network using Labeling Algorithm." The thing I was looking for was a shortest path algorithm with "nondeterministic weights." The problem is actually quite common (happens with traffic as weights change with time) and has a ton of research published on it. I thought the problem I mentioned might be intractable too but it turns out it is not [img]http://public.gamedev.net//public/style_emoticons/default/smile.png[/img]. It says that as long as the weights are known ahead of time (not random as with traffic and can be listed or represented using a function), the problem is not intractable. [img]http://public.gamedev.net//public/style_emoticons/default/smile.png[/img] Though, yeah, having to backtrack to find out what the possible weights are is going to slow down an already slow polynomial time algorithm he he he. Thanks!
  3. Exactly guys! You guys are all right on it... it would either require a massive expansion of nodes or probably a metaheuristic to solve! I'm just silly lol. Ever had that thought where you say ok I'm going to add a little twist to an existing problem to see if I can get better results only to find out that what you're trying to do is silly or impossible :-)? I'm surprised I couldn't find anything on google about this type of problem... "Graph" "shortest path" "multiple weights" "conditional weights" etc... turned up nothing!
  4. I'm trying to implement a minimal/shortest path type problem. Normally, you'd think Dijkstra or some other algorithm would work, but this is a special type of graph where the weights aren't fixed. For example, if the problem was like this, it would be easy (just use Dijkstra): [img]http://i73.photobucket.com/albums/i206/yadango/graph1.jpg[/img] However, the problem I have is like the following. [img]http://i73.photobucket.com/albums/i206/yadango/graph2.jpg[/img] Think of it like this... because A -> D is downhill and D -> E is uphill, the weight for D -> E is 1. Because B -> D is flat and D -> E is uphill, the weight for D -> E is a little larger, 5. Because C -> D is uphill and D -> E is uphill, consecutive uphill are a doozy for the enemy and so he has a weight of 9. In other words, any weight along the path doesn't just depend on where you were previously, but where you were before that too. It can even extend farther back several levels like going uphill 3 times in a row is a real doozy and you must pay an extra penalty for that too. I've thought of a bunch of stuff, but backtracking requires a lot of memory especially when the graph gets large and so far the only solution I've come up with is to just test all possible paths (since enemies are usually close to the player the graph doesn't get too large but for even small graphs testing all possible paths takes too much time). Has anyone seen a problem like this before? Is there an algorithm for it? Algorithms like Dijkstra, Viterbi, etc. don't work because they assume only one weight per edge. Thanks!
  5. Why not call DialogBox after calling CreateWindow? That will show your modal dialog and window at the same time. I don't think there's a way to do it from a window proc, albeit using timers. However your first post indicates you are calling CreateDialog and using it in combination with EndDialog, which is incorrect usage. CreateDialog also shouldn't hide your parent window. You should post your sample source so we can pick it apart.
  6. C# is it's own language... I wouldn't say it's an exact combination of anything because the libraries and many components such as generics are quite different. It came about out of the Sun-Microsoft fiasco many years back over the language known as J++ or something like that. They hired the guy from Borland/Inprise who created Delphi to construct a new language similar to Java with the benefits of Delphi (some people consider the VCL a precursor to the FCL). So C# is really, if anything, a Java/Delphi hybrid he he he. C# was dubbed the Java-Killer for a long time but it didn't really kill Java; you could say it killed Delphi though.
  7. Lol i would only use it if I had to use it.... Targeting win95 or win32s if oh god some people remember that far... Did vc6 still generate windows 3.1 binaries? Another reason to use it is if you have to use it. I taught a vb class recently and department told me not to use modern vb.net. Book also used old vb and provided vb working model. So sometimes classes are taught using classic versions of the language.
  8. so maybe something like this? [img]http://public.gamedev.net//public/style_emoticons/default/smile.png[/img] that's why the mask has to be in order... [source lang="cpp"]// mova a0.w, r4.x temp.x = r4.x temp.y = r4.x temp.z = r4.x temp.w = r4.x a0.x = unchanged a0.y = unchanged a0.z = unchanged a0.w = temp.w // mul r4.yzw, v0.y, c0[a0.w].xxyz temp1.x = v0.y temp1.y = v0.y temp1.z = v0.y temp1.w = v0.y temp2.x = c0[a0.w].x temp2.y = c0[a0.w].x temp2.z = c0[a0.w].y temp2.w = c0[a0.w].z r4.x = unchanged r4.y = temp1.y * temp2.y r4.z = temp1.z * temp2.z r4.w = temp1.w * temp2.w[/source]
  9. Cool, thanks, makes sense now! The repeat rule only applies to the source register and not the dest.
  10. Hey guys, Is it ok to call MessageBox with an active device and swap chain? Just by chance I forgot to rename a compiled shader file... and the following code started to crash on the MessageBox line. But if I move the MessageBox line to below the FreeDirect3D call, the message box displays fine. I'm on on an AMD card with latest drivers running a sample D3D11 application in windowed mode. Thanks! This crashes. [source lang="cpp"]// open vertex shader std::ifstream vsfile("002.vs", std::ios::binary); // oops! wrong filename if(!vsfile) { MessageBox(GetMainWindow(), TEXT("Failed to open vertex shader file."), TEXT("Error"), MB_ICONSTOP); // crash! FreeDirect3D(); return FALSE; }[/source] This works OK. [source lang="cpp"]// open vertex shader std::ifstream vsfile("002.vs", std::ios::binary); // oops! wrong filename if(!vsfile) { FreeDirect3D(); MessageBox(GetMainWindow(), TEXT("Failed to open vertex shader file."), TEXT("Error"), MB_ICONSTOP); // OK! return FALSE; }[/source] EDIT: After some more testing, for me, any MessageBox called after D3D11CreateDeviceAndSwapChain but before a call to CreateVertexShader crashes atidxx32. Any MessageBox after the call to CreateVertexShader doesn't crash. [url="http://www.sticklove.com/003.7z"]Full source code[/url] crashes on line 47 of d3dapp.cpp.
  11. If looking for some easy sample source code... you can also look at my page, where I have a sample pac-steve game that I used to teach the into web programming course at my school. If I recall right I used JavaScript prototypes so it won't run in most default mobile browsers but the prototypes can be removed fairly easy to make it purely procedural. Biggest problem to watch out for as already mentioned are things like timing... there are no high-resolution timers and it is a challenge to get most mobile browser games to perform equally on different browsers running on different systems. Sound is also a challenge; back when I wrote pac-steve, the audio was so choppy I had to remove it (don't know how it is now a year later though). [url="http://www.calstatela.edu/faculty/semory/"]Pac-Steve[/url]
  12. I find that using standard formats are overkill for use in games. Very few professional games use collada or x files. You want your data to be read quickly so I prefer chunk based binary formats. A lot of games like dynasty warriors use chunk based formats. Many games like any using Sony phyrengine use a binary scene graph format. Hyper dimensions neptunia also uses scene graph based format. Many games like saints row the third use flat binary files. Use whatever you want just be sure you can read the data fast.
  13. Near plane is like a physical window. Light hits objects outside window, reflect onto window, and that is what you see through the window. Your monitor is like a window. Far plane is there to limit how far you can see through that window. It's essentially a wall that is placed very far away that limits how far you can view.
  14. Hello, I'm trying to learn HLSL assembly, using MSDN as a guide and a book or two. Most swizzle examples given are kind of simple and I saw some code that looked like this and wondered what the equivalent statements were. [source]mova a0.w, r4.x mul r4.yzw, v0.y, c0[a0.w].xxyz [/source] is the equivalent expression [source]a0.w = r4.x r4.y = v0.y * c0[a0.w].x r4.z = v0.y * c0[a0.w].x r4.w = v0.y * c0[a0.w].y[/source] or this? [source]a0.w = r4.x r4.y = v0.y * c0[a0.w].x r4.z = v0.y * c0[a0.w].x r4.w = v0.y * c0[a0.w].y r4.w = v0.y * c0[a0.w].z[/source] Thanks!
  15. Like this. #include <windows.h> HWND hOknoApl; //main window HWND msgWindow; //messageWindow HWND commandLine; //commandWindow //declarations LRESULT CALLBACK ProcOkna (HWND, UINT, WPARAM, LPARAM); LRESULT CALLBACK CommandWindowProc(HWND, UINT, WPARAM, LPARAM); WNDPROC BaseCommandWindowProc = 0; bool UtworzOknoAplikacji(HWND *hWnd, LPSTR lpszTyt, int szer, int wys); //main window parameters int szerokoscMain=230; int wysokoscMain=200; int WINAPI WinMain(HINSTANCE hProgram, HINSTANCE, LPSTR, int swPokaz) { //main window creating if (!UtworzOknoAplikacji(&hOknoApl,"Ciekawe okno",szerokoscMain,wysokoscMain )) return false; ShowWindow(hOknoApl,swPokaz); //adding textboxes msgWindow = CreateWindowEx(WS_EX_CLIENTEDGE,"EDIT",NULL,WS_CHILD|ES_AUTOVSCROLL| ES_MULTILINE, 5,10, szerokoscMain -25,wysokoscMain - 75, hOknoApl,NULL,hProgram,NULL); commandLine =CreateWindowEx(WS_EX_CLIENTEDGE,"EDIT",NULL,WS_CHILD, 5,wysokoscMain - 62, szerokoscMain -25,20, hOknoApl,NULL,hProgram,NULL); ShowWindow(msgWindow,SW_SHOWDEFAULT); ShowWindow(commandLine, SW_SHOWDEFAULT); SetWindowText(msgWindow, "Witamy w programie!"); BaseCommandWindowProc = (WNDPROC)SetWindowLongPtr(commandLine, GWLP_WNDPROC, (LONG)CommandWindowProc); if(!BaseCommandWindowProc) MessageBox(hOknoApl, "Failed to set window proc.", "Error", MB_ICONSTOP); //getting messages MSG msg; while(GetMessage(&msg,NULL,0,0)) { TranslateMessage(&msg); DispatchMessage(&msg); } return msg.wParam; } LRESULT CALLBACK ProcOkna (HWND hOkno, UINT uMsg, WPARAM wPar, LPARAM lPar) { switch(uMsg) { case WM_SIZE: //When you switch the window size MoveWindow(msgWindow,5,10,LOWORD(lPar) - 10,HIWORD(lPar)-37,true); MoveWindow(commandLine,5,HIWORD(lPar) - 25,LOWORD(lPar) - 10,20,true); break; case WM_DESTROY: //after destructing window PostQuitMessage(0); break; case WM_GETTEXT: /* ### here I wanted to get the given text and set it as msgWindow text ### */ case WM_SETTEXT: SetWindowText(msgWindow,(LPTSTR)lPar); break; default: return DefWindowProc(hOkno,uMsg,wPar,lPar); } return 0; } bool UtworzOknoAplikacji(HWND *hWnd, LPSTR lpszTyt, int szer, int wys) { //Getting program handle HINSTANCE hProg = GetModuleHandle(NULL); //Main window class registering WNDCLASS wc; wc.lpszClassName = "Ciekawe Okno"; wc.hInstance = hProg; wc.lpfnWndProc = ProcOkna; wc.style = 0; wc.hIcon = LoadIcon(NULL,IDI_WINLOGO); wc.hCursor = LoadCursor(NULL,IDC_ARROW); wc.hbrBackground = GetSysColorBrush(COLOR_BTNFACE); wc.lpszMenuName = NULL; wc.cbClsExtra = 0; wc.cbWndExtra = 0; if(!RegisterClass(&wc)) return false; //Window creating *hWnd = CreateWindowEx(0,"Ciekawe Okno",lpszTyt,WS_TILEDWINDOW, CW_USEDEFAULT,CW_USEDEFAULT,szer,wys, NULL,NULL,hProg,NULL); if(*hWnd==NULL) return false; else return true; } //============================================================================== LRESULT CALLBACK CommandWindowProc(HWND window, UINT message, WPARAM wparam, LPARAM lparam) { switch(message) { case(WM_KEYDOWN) : { if(wparam != VK_RETURN) return CallWindowProc(BaseCommandWindowProc, window, message, wparam, lparam); int index = GetWindowTextLength(msgWindow); SendMessage (msgWindow, EM_SETSEL, (WPARAM)index, (LPARAM)index); char buffer[1024]; GetWindowText(window, buffer, 1024); SendMessage(msgWindow, EM_REPLACESEL, 0, (LPARAM)((LPSTR)buffer)); return 0; } } return CallWindowProc(BaseCommandWindowProc, window, message, wparam, lparam); }