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

hstubbs3

Members
  • Content count

    17
  • Joined

  • Last visited

Community Reputation

172 Neutral

About hstubbs3

  • Rank
    Member
  1. If there is some limit on the number of objects, you could allocate a static array, and then loop through it when you need to edit / draw /etc ( just skip any of the objects / pointers that are "null" or otherwise aren't valid at the time.. ) otherwise - creating a dynamic container - vector, list, etc.. and iterate on it.. it sounds like you are getting accessviolation exception trying to go beyond bounds of the original array? or how are you trying to create the array of buffers ( or use it - where is the exception coming from ?? )
  2. for the 2nd part of the question - move the center point without affecting the gradient itself... Just move the center point... example - your new 'center' is (0, .5 , 0) .. so subtract .5 from Y and look up the value there.. Generalized, a function f of vertex P [ f(p) ]can be solved at a new 'center' c using f(p - c) .. Written out longform this means substituting ( pX - cX ) everywhere you were using just X before, same with Y and Z. As for the 1st part.. should just be sqrt(x^2 + y^2 + z^2 ) - the gradients would change according to sphere radius.. like layers of an onion.. So ( 0,0,0 ) is black core.. ( 0, 1, 0 ) is white point ( "north pole" )
  3. Oops.. forgot the last bit as well... So - if any combatant needs info on another combatant, it just accesses the base-class ( or higher class through an interface / virtual function ).. No combatant knows or cares what is "brains" - only if they are "friend" or "foe" or if they're attacking, etc.. etc..
  4. "Player" and "Enemy" don't sound like distinct classes to me - they are "combatant" "Combatant" has speed, position, possibly weapons, inventory, etc.. Then "Player" is a class derived from "Combatant" - uses input (keyboard,mouse, etc.) to change animations, positions, etc. And "Enemy" is also class derived from "Combatant" - but this uses AI to drive it... This would also allow later for AI characters to fight on either side, or possibly have multiple factions... And networked / LAN players could be derived as well...
  5. It was a camera "trick" of sorts - the Super NES had "mode 7" to handle the character sprites, scaling and what-not... The track was just raycast, probably tile-based too. . . The was a DOS shareware game that had similar look/feel to Super Mario Kart - Wacky Wheels . . you might be able to find source codes and such googling for that..
  6. there's filters you can try and pull out the guitar part.. otherwise, maybe if you just used MIDI of the songs?? as for the note storage... why not MP3, with a file containing the offsets for each note, so the prog knows how long to cut out the song if you screw up.
  7. I'd say you have a good bet.. then again, just check dell.com 's support section for your system's specs..
  8. without double-checking the equation (b/c working in a factory just sucks it out of you... ) there's 3 possible scenarios.. not 2.. a) no intersection - iirc your square root will be imaginary (so first check make sure that whats under it isn't negative...) b) 1 intersection (square root is 0) - the moving circle becomes *tangent* to the second one at some instant.. c) 2 intersections - (square root +/-) - first collision is smallest t > 0 . negative t means movement backwards...
  9. um... the FreeWare one... :-P ie - somewhere in your distribution you put the license agreement (something along the terms of - this software is MINE and all shall hail me for writing it, but you can pass this piece of programmed excellence freely. . . in fact, you should do so, because then when you see my name on another awesome game you will not question its quality. . and NO you may not get the source code for this project or reverse engineer it for any purpose. ... ) EDIT - darn it, i was too busy being egotistical and got beat .. . lol
  10. as for the For loop... ok, so i'm an idiot... but even fixing that i still have an issue... first-chance exception - Microsoft C++ exception: long at memory location 0x0012fd08 ... somewhere in DrawPrimitive ... the prorated loop was originally intended to limit to about 50fps . . . i was gonna eventually animate these things. . then it was crashing out on an unhandled exception so i put a messagebox in there and it was crazy.. lol. . so yeah.. . 1000 is way too long to wait usually... but still kinda lost.. Oops.. . left out setstreamsource .. . heh... ok. . so now i don't have exceptions,.... still just black.. got to check the winding of the polys or something i guess... thanks for the help tho ....
  11. thx for the tag thingy.. . still lost on the error though :-/ might just try and simplify until it works... meh. .
  12. I'm just lost... I'm just messing around with some code (i'm more noob than I realised... ) that's supposed to render several squares (32x32 px) in just white using 2 triangles per... and its just not working... first I was getting a read access violation trying to lock my vertex buffer, which is stored in a global pointer (never mind how evil that is, give me a break) ... in my message pump i had a call to a function called render_frame() that would copy the vertex list to the buffer for rendering. . . the buffer is created in winmain ... debugging just stopped at buffer->lock(0,0,(void**)pVoid,0); (in render_frame() ) with the violation address being pVoid + 0x10 .. ?? .... I moved the contents of render_frame to just be in winmain's message loop, and now i just get first-chance exception - long at memory location. . i think its &pVoid.. I'm just confused by that all. . anyways, here my code. . . note - I currently do get a window which is just black, 640x480 ... that much of my code works (its framework from me following a tut on d3d9 .. ) //we'll include windows and directX headers in luci.h! #include "luci.h" #define NUM_BOXES 15 #define CUSTOMFVF (D3DFVF_XYZRHW | D3DFVF_DIFFUSE) struct myvertex{ FLOAT x,y,z,rhw; DWORD color;}; struct MyMove { FLOAT x, y; }; struct MyBox{ FLOAT left, up, right, down; MyMove V; DWORD color; } ; // color=D3DCOLOR_XRGB(0, 0, 255) MyBox TheBoxes[NUM_BOXES]; myvertex BoxPolys[NUM_BOXES][6]; int WINAPI WinMain (HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int CmdShow) { if(LuciCreateMainWindow(hInstance, CmdShow, false,640,480)) return 1; initD3D(); LPDIRECT3DVERTEXBUFFER9 triangle_buf=NULL; d3ddev->CreateVertexBuffer(6*NUM_BOXES*sizeof(myvertex),0,CUSTOMFVF, D3DPOOL_MANAGED,&triangle_buf,NULL); int b=0; float screen_x=8; float screen_y=8; for(int y=0; y<(NUM_BOXES/15)+1; y++) { screen_y+=40; screen_x=8; for(int x=0; x<15; x++) { screen_x+=40; TheBoxes[b].left=screen_x-16.0f; TheBoxes[b].up=y-16.0f; TheBoxes[b].right=x+16.0f; TheBoxes[b].down=y+16.0f; TheBoxes[b].color=D3DCOLOR_XRGB(255, 255, 255); b++; } } MSG msg; DWORD starting_point; bool DeviceLost=false; HRESULT DeviceErrCode; while( TRUE ) { starting_point = GetTickCount(); if(PeekMessage(&msg,NULL,0,0,PM_REMOVE)) { if (msg.message == WM_QUIT) break; TranslateMessage(&msg); DispatchMessage(&msg); } if(DeviceLost) { DeviceErrCode = d3ddev->TestCooperativeLevel(); if(DeviceErrCode == D3DERR_DEVICENOTRESET) { if(d3ddev->Reset(&d3dpp)==D3D_OK) DeviceLost=false; } } if(!DeviceLost) { for(int i=0; i<NUM_BOXES; i++) { BoxPolys[i][0].color=BoxPolys[i][1].color=TheBoxes[i].color; BoxPolys[i][2].color=BoxPolys[i][5].color=TheBoxes[i].color; BoxPolys[i][0].x=TheBoxes[i].left; BoxPolys[i][0].y=TheBoxes[i].up; BoxPolys[i][1].x=TheBoxes[i].right; BoxPolys[i][1].y=TheBoxes[i].up; BoxPolys[i][2].x=TheBoxes[i].left; BoxPolys[i][2].y=TheBoxes[i].down; BoxPolys[i][3]=BoxPolys[i][2]; BoxPolys[i][4]=BoxPolys[i][1]; BoxPolys[i][5].x=TheBoxes[i].right; BoxPolys[i][5].y=TheBoxes[i].down; } //triangle creation code VOID *pVoid; triangle_buf->Lock(0,0,(void**)&pVoid,0); memcpy(pVoid,BoxPolys,sizeof(BoxPolys)); triangle_buf->Unlock(); d3ddev->Clear(0, NULL, D3DCLEAR_TARGET, D3DCOLOR_XRGB(0, 0,0), 1.0f, 0); d3ddev->BeginScene(); d3ddev->DrawPrimitive(D3DPT_TRIANGLELIST,0,NUM_BOXES*2); d3ddev->EndScene(); if(d3ddev->Present(NULL, NULL, NULL, NULL)!=D3D_OK) { DeviceLost=true; } } while((GetTickCount() - starting_point) < 1000) ; } triangle_buf->Release(); closeD3D(); // LuciMB(L"Exiting Now"); return msg.wParam; } LRESULT CALLBACK WindowProc(HWND hWnd, UINT message, WPARAM wParam, LPARAM lParam) { switch(message) { case WM_DESTROY: { PostQuitMessage(0); return 0; } break; default: return DefWindowProc(hWnd, message, wParam, lParam); } return 0; } [Edited by - hstubbs3 on June 21, 2008 8:50:01 PM]
  13. they're moving the same vector in world-space, but on-screen that translates into moving away from the 'vanishing point' . . if the character should really be moving per the screen and isn't in the middle, you'd have to skew Z axis movement towards the camera .... ie - "right" is right and "left" is left.. .but down is vector pointing towards camera's projection into the movement plane, and up its opposite... i mean, if camera is at (0,10,0) and movement is considered on the ground plane then you're pointing at (0,0,0) wait.. i just went cross-eyed... Whheeeeeeeeee!
  14. you should be more specific..... wait.. hell no. . I got a better one... never mind visual studio.. isn't there an open source project that lets you make your own 2d fighting game stuff??? spekin de which. .. you mean MK1 right??? don't you need actors for that? and video cameras? ? ?