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

LancerSolurus

Members
  • Content count

    238
  • Joined

  • Last visited

Community Reputation

630 Good

About LancerSolurus

  • Rank
    Member
  1. According to their website, you can use any assets you create in commercial and non-commercial products. The only exception is the source code. Short answer is yes.
  2. Yes, I'm over using goto according to pro standards but not my standards. I know I will never work in the professional arena (only happened once using c#) so I program the way I'm most comfortable with. The code you saw (which I shouldn't have posted) is simply copy/paste for each type of section. It can parse over 900 files in less than 4 seconds, the cache hits are negligible unless someone really has a trashy INI file. I make sure mine are clean and jump back to lp:. What I posted is at the top of the routine and is fully in the cache, even the subroutines. I don't create a new function unless it's used more than once. Anyways the question I asked in the OP has been fully answered, I will never make it in the pro world with my programming style. Cudos to those who posted before i got switched forums. this should have been left in the GDNet lounge. 
  3. @iMalc, I live in an area of the country where Fortran, Cobol and C programmers are in high demand lol, sorry c++ is the lowest I'm willing to go. Will do c# if needed for a tool but it isn't needed around here. At work our OS is Win 98, no thanks, I left VS 6 many years ago...
  4. I could see where a boolean would work in that case. Anyways most of my code isn't written that way, I uses lots of if statements, for loops, breaks and continues where applicable, subroutines, returns etc. Just wondering, I don't know of any statement besides goto that could be used to break out of an if statement.   I could understand that you would quit if you had to work on my code, the example I gave was the most extreme use of it in my code, The naming though I have no trouble with, been using the same short style names for over 20 years, consistency counts a lot. If I don't remember it I say it out loud then it pops into my head, I did just take a year long break from programming of any sort and when I went back to it I had no trouble reading it. I didn't post the whole routine either but it is just test after test like that. It's fast, cache friendly and very stable.   Another thing I do is for loops, i,li, j,lj, k,lk, most would give them names, I don't. I start at i and go through the alphabet. i is the loop counter and li is limit counter, always a pair, always in order. I did a little research on RAII and it seems I have been programming my routines that way for a long time, albeit manually, since I use all custom memory handlers and reference counting. They all handle their own cleanup on exit as well, fairly easy to do with classes.   Now when it comes to routine names, those are usually fully spelled out except Rem(ove). I have a class template I use for every new class and a program to create it for me. I just name the parts and it spits out a new class ready to plug in. Takes less than a minute to have a fully functional dynamic memory/rendering class to use.   EDIT: Wanted to show what I mean about being fast, click on my youtube link below and watch the wandering video, 5% is INI parsing, 95% is DX loading the data. Most of the textures it loads is 1024 x 1024. I will switch to streaming eventually but this will show you that the bottleneck is not the spaghetti code I posted.
  5. Thats just an example, I don't know beforehand how long the script is in line count. Goto unknown command is there since if rv=false then that is a command that isn't part of that section. If rv=true then it was a valid line so go parse the next line. For ex. if a model had a range attribute (part of the light section) it is an invalid command and should be logged as such.   The end of script test is done by this line... if(DBFIO.IsPastEOS()==true) goto ex;   The read_line(something) won't work since spl is an array, it's the line split into individual items, the command and all of it's parameters. It also has no return value other than split line (spl). The way it works is it checks for a valid section header such as [light], if it isn't that it continues parsing the individual lines of the current section till it hits another header.   As far as sensible names, they make perfect sense to me, short and descriptive. Less typing as well. Yep, it comes from my background in assembly. The names could be up to 255 characters back then though. Like I said, I'm set in my ways and one of them is short names. DynObj is a dynamic object model loaded from a script. For the naming, notice each word starts with a capital, ie Cur(rent) L(i)n(e)C(ou)nt, usually vowels are dropped. Also, I'm the only one who will ever work on the code and won't be releasing it. That code is quite legible compared to some of the legacy code still hanging around in my core library.   Anyways any other methods are welcome, always up for learning new things.... 
  6. I will post a snippet from my parser which is one of the routines I needed goto the most... lp: if(DBFIO.IsPastEOS()==true) goto ex; DBFIO.ParseCmdLineF(spl); // splits up line CurLnCnt++; if(spl.Cmd=="") goto lp; // empty line spl.Cmd.MakeLower(); And further down in the parsing stage... if(md==true) { rv=Prs_Model(spl,cur); if(rv==true) goto lp; goto unkcmd; } if(obj==true) { rv=Prs_Object(spl,cur); if(rv==true) goto lp; goto unkcmd; } if(dyn==true) { rv=Prs_DynObject(spl,cur); if(rv==true) goto lp; goto unkcmd; } if(lt==true) { rv=Prs_Light(spl,cur); if(rv==true) goto lp; goto unkcmd; } At at the end of the routine is the final cleanup/error reporting... if(fcts==true) { rv=Prs_FctShips(spl,cur,cur2); if(rv==true) goto lp; goto unkcmd; } goto unkcmd; ex: return rv; ovf: ts.Format("Parser : Overflow detected -> %s in line %u",spl.Cmd,CurLnCnt); DB3D.LogError(ts); goto lp; unkcmd: ts.Format("Parser : Unknown command '%s' at line #%u in '%s'",spl.Cmd,CurLnCnt,CurFlnm); DB3D.LogError(ts); goto lp; unksect: ts.Format("Parser : Unknown section '%s' at line #%u in '%s'",spl.Cmd,CurLnCnt,CurFlnm); DB3D.LogError(ts); goto lp; synerr: // syntax error ts.Format("Parser : Syntax error : '%s' at line #%u in '%s'",spl.Cmd,CurLnCnt,CurFlnm); DB3D.LogError(ts); goto lp;
  7. I also avoid exceptions at all costs. The only time I use them is with file I/O routines. I use the try function and then include a catch block immediately below it. If there is an error I log it and pass it back through the return value. I even have dedicate log routines for plain text, DX errors that use getlasterror for the full error description and several others. Even when I code I build error checking into the code as the routine is constructed. I even split the log into a runtime log and an exit log in-case of a crash during exit. It is also saved to a temp log each time a new scene is loaded in-case of a crash.   That was a good article Promit.
  8. Wow, a lot of posts in 2 days, thanks for all of the replies. I believe Bacterius explained it pretty much the  way I use it, cleanup. If I create using new, it needs to be deleted before I leave the routine, otherwise I incur a memory leak. I use break and continue as well. Mainly it's because I'm set in my ways and have no trouble following my own code. I always use the exact same labels for every goto. For exit and cleanup routines, it's ex:, if I want to use a loop without the hassle of dealing with a for statement, it's lp:. On rare occasions I need to reinitialize the loop by going above that code, it's always lp0:. I don't use it a huge amount but it works like this for me, code not executed is CPU cycles not wasted, the same principle of the early Z fail for GPUs.   As far as the 1000 lines of code, that was just an example. None of my routines are that large, but the main INI parsing routine comes close (913 lines). Due to it being written that way I can run through 918 INI files in less that 4 seconds because of it being in the cache and it is looping back to the beginning. The most used commands are the first checks such as models and lights.   Anyways it's just the way I program, I doubt I will ever have a job in the industry. I use computers at work but it's just for inventory management, nothing more. I'm quite used to it and it may look like spaghetti but I can easily read it due to that I use consistent naming. I haven't use RAII in over a decade, forgot what it's even used for ;)   I am interested in some of the other methods of avoiding it that have been mentioned here, if you folks wouldn't mind explaining some of them to me, I would be much abliged for your help,
  9. I am an old school programmer, did many stints in assembly (6502,6510,68000,68030,486,586), basic, fortran, pascal, extended languages, c++, c# etc... I use goto on a regular basis to exit out of routines, skipping many lines of code and only incurring a single cache hit. In over 30+ years I know when the proper use of the command is needed, it's no worse than BREAK or CONTINUE for a loop, actually less in fact. What is your aversion to using that command, is it your workplace or your training? I can skip a thousand lines of code with a single command and a single cache hit. Do you have to jump through hoops to get out of a routine? With my experience I know when to use it and not to use it. I want to hear from the professionals why it's such a bad command to use. My typical use is goto ex; which is jump to the exit routine, everything is done, clean up and get out. I'm not a pro by any means (mid-south US, no programming jobs here), just wondering about all the hate on goto is about, it's a very useful command...
  10. I would suspect the dark area behind the cube is beyond the edge of your shadow map. I had an issue like that, I simply did a range test for the edge and didn't render the shadow beyond that. Later on I will go back and see if it's possible to adjust texture clipping to nullify the need for the range test. Just an idea of what it may be...
  11. You could try out Torque 3D, it's now open source, the main downside is limited mobile support.
  12. Going back to an earlier version of the docs before most was removed, this is the formulas shown. I have found stuff in the older version that isn't even online (March 2009 version), which is pretty much the same thing your link shows.   There are two options for calculating depth bias. If the depth buffer currently bound to the output-merger stage has a UNORM format or no depth buffer is bound the bias value is calculated like this: Bias = (float)DepthBias * r + SlopeScaledDepthBias * MaxDepthSlope; where r is the minimum representable value > 0 in the depth-buffer format converted to float32. The remaining values are structure members. If a floating-point depth buffer is bound to the output-merger stage the bias value is calculated like this: Bias = (float)DepthBias * 2**(exponent(max z in primitive) - r) + SlopeScaledDepthBias * MaxDepthSlope; where r is the number of mantissa bits in the floating point representation (excluding the hidden bit); for example, 23 for float32. The bias value is then clamped like this: if(DepthBiasClamp > 0) Bias = min(DepthBiasClamp, Bias) else if(DepthBiasClamp < 0) Bias = max(DepthBiasClamp, Bias) The bias value is then used to calculate the pixel depth. if ( (DepthBias != 0) || (SlopeScaledDepthBias != 0) ) z = z + Bias
  13. I've been programming over 30 years now and didn't have the advantages you have now (started on a Vic 20). As Frob said, use both, I could have really used the extra help all those years ago, hehe, a stone age programmer I know. Any time I want to create a new feature I now google it first to see if it's been figured out by someone smarter than myself. It's not cheating, it's smart thinking and time saving on your end.
  14. Workaround for driver lockups - requires a 1680x1050 or 1920x1080 resolution   Well I did do a work-around to the total system lockup, thought I would share this as well. Convert the render to windowed mode, I set mine to 3/4 1920 by 1080, gives a little room for the task manager to show. Start task manager before debugging. Edit a single file even if it's adding a space then deleting it, this will give you time for the next step. Start debug (F5 for me in VS), click on task manager in the task bar (the edit gives a few extra seconds). When it screws up, right click your exe and kill it, if you have left click over-ridden as I do, Select 'End Process Tree' and hit Enter then hit Enter on the next dialog window. This will kill your process and keep you from having to reboot your system. For the vets most of you already know this, just posting this for the beginners.
  15. That I will do. During the time I was tracking down the problem a new driver was released. Didn't clear up the issue either, Even tested the beta driver between the two which I never do.   It pretty much locks it down to a driver bug since the 250 didn't have this issue. The only changes was new drivers and the 750 being installed.   Anyways, thanks for everyone's input on this, it's much appreciated!