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

SGreth

Members
  • Content count

    291
  • Joined

  • Last visited

Community Reputation

218 Neutral

About SGreth

  • Rank
    Member
  1. Hey GDers! Holy cow, has it seriously been 6 years since my last post? Although I'm not doing game development at the moment I am still coding and my latest project is [url="http://photomonkee.com"]photomonkee[/url]; an OpenCL (no, not GL) accelerated photo editor. [attachment=6555:screenie.PNG] I know that some of you create your own art assets and would love to get your input on what features I could add to the software to help. If you'd be interested in taking it for a test driver feel free to sign up at the site or drop me a message on here. [color=#000000]In terms of functionality, PhotoMonkee has a lot of the basics you'd find in a paint program plus a few extra bells and whistles. Don't get me wrong, it's no PhotoShop but it certainly isn't MSPaint either [/color][img]https://www.evernote.com/shard/s52/res/353c76e0-e49a-4959-8255-7a42f5419b45.png[/img][color=#000000] [/color][list] [*]Basic Tools [list] [*]Brush [*]Scale/Rotate/Translate [*]Magic Wand [*]Text [*]Eraser [*]Pixel Selection (with additive and removal modes) [*]Flood Fill [*]Basic Shapes [*]Canvas Zoom [*]Color Picker [/list][*]Layering System [list] [*]Blending [*]Opacity [*]Styles (only drop-shadow so far) [/list][*]Canvas Cropping and Size Modification [*]Color Palette system with support for RGB, HSL, HSV and CMYK color models [*]Filters [list] [*]Color Inversion, Gray-scale, Sepia [*]Brightness/Contrast [*]Color Adjustments [*]Sharpen, Emboss, Smooth (Convolution Filters) [*]Jitter, Pixelate (displacement filters) [/list][*]Copy/Paste from within the application and between other applications [*]Unlimited Undo/Redo [*]Import from all of QImage's supported types (png jpg bmp gif pbm pgm tiff xbm xpm) [*]Export to all of QImage's supported types(bmp, jpg, png, ppm, tiff, xbm, xpm) [*]Save/Load via the PhotoMonkee file format *.pm (no, not PERL modules, silly!) [/list] Thanks in advance for any help and suggestions. Happy New Year!
  2. Yeah, the option of having dead code, or an branch for every vertex...the choice was obvious :)
  3. Yeah, this morning I was considering either doing that, or setting a global shader boolean parameter indicating if the sampler should be used. I'll just bind the two technique types as that would be less of a performance hit. Thanks guys, ~S'Greth
  4. In short I'm looking to check if a texture is bound to texture stage 0. If it is, sample that register, otherwise, just use the vertex color. I couldn't find any built-in HLSL functions to query if a texture stage was bound or not. (note: this shader doesn't work, it's just pseudo-code. texture tex0 : Texture1; sampler2D SpriteSampler = sampler_state { texture = (tex0); mipfilter = LINEAR; }; float4 PS(VS_OUTPUT In) : COLOR { float4 color; if(SpriteSampler != NULL) { color = tex2D(SpriteSampler, In.TexCoord); } else { color = In.Color; } return color; } // end of PS Thanks, ~S'Greth
  5. Bingo! That was it, thanks a bunch. I'm going through converting all my old fixed-function stuff to use the effect framework. It's been going way too smooth until that little kink. If that's the only bump in the road this isn't too bad :) Thanks again, ~S'Greth
  6. I'm using an effect/technique to render two seperate objects. The first time I use the shader I bind TextureA to it and draw. The second time I use the shader I bind TextureB and draw. Oddly enough, the textures used for the objects are opposite what I expect them to be. I.E. the first object ends up with TextureB and the first has TextureA. I *could* create a new effect object for every element, but that just seems like a waste. One would think re-binding the texture would work OK. Is that the case? Thanks, ~S'Greth
  7. Spent last night starting a particle system framework. I've made 3D particle systems in the past for rain, lighting, and sparks. With that in mind, I'm doing a 2D game, but trying to keep the core graphics library 3D-centric. Currently I'm working on the basic particle emitter types and then I'll tie them in with the particle system and particle classes. Hopefully I'll have enough time this weekend to get this wrapped up enough to integrate into both the editor and the game. A buddy of mine got me hooked on a really fun web-based RTS (and I use the term RTS loosely here...) It's called ogame and it's great if you don't have hours & hours & hours to burn on a game, but you want to get your fix (i.e. at work!!!). I'm only a couple of days into it, but I'll be keeping up on this one for sure. I was seconds away from actually purchasing WoW, and thank goodness I didn't...I'm making great progress on my game-hobby addiction :)
  8. I tossed in editor support for picking a level background and then the game engine support to draw it. All I need now is a score counter and I'd have a very basic shell of a game! After which of course comes the fun part...polish & eye-candy (the fun parts). I started implementing support to stream OggVorbis files using OpenAL and then I found a fantastic article with a working implementation along side it: http://www.devmaster.net/articles/openal-tutorials/lesson8.php A great read for those who are looking for a totally free sound solution (i.e not FMOD). I'm going to spend tonight integrating the class that the author wrote into my framework and perhaps put some fade in/out capabilities into it as well to make transitioning better. I've got a host of things I can run with after the music starts cranking: - in-game console (I already have this coded in my core library, just need to integrate it). - Particle Effects - Animated sprite system - Proceedural textures (CPU & GPU generated) - 3D level backgrounds/scene - Tighter collision (i.e. sphere to rectagle instead of rect to rect) - Power up/down system - Bonus point system - Level timer - Score tracking/display - "lives" tracking/display - pre/post game menus (incluing a game state system) - In-game pause - High score system - Level 'packs' - Install program for the entire lot (need this before I do any demos...) This morning I also integrated both full and windowed screenshot taking capabilities into my core graphics library. To test it out, here is a screenie of the game as it is now. Sorry for the HORRID graphics...sooner or later I'll get my buddy to make some good block, background, and border textures.
  9. I got the basics of my OpenAL wrapper finished yesterday. I added support into the editor to assign a sound when a block is hit. I tossed in support over in the game as well to play the sound when the block is hit. The only major bug/stumbling point I hit was that you can de-allocate an OpenAL sound buffer while it's currently in use by a source.I *would* link a buffer to the source(s) that it's currently being played from, but the problem is that there is no way to be notified when a sound has finished playing in source's queue. For now I'm just resorting to stopping all sound output from a source and clearing that source's queue before. Hopefully that's not *too* ghetto :) ~S'Greth
  10. Slowly moving forwards is better than sitting idle :) I've been throwing bits & pieces of code together, but not at the rate I want to really progress. At any rate, I've got the basics of a level editor in place, it exports 'em and now the game will start up and load up the demo level. Granted, there are no bonuses, power ups, sound, or special effects, but the ball bounces around the level, responds to hitting bricks and the paddle. Good start...now it's time to add all the fluff. I think the next item on my list is to encapsulate OpenAL into a nice little library for me to use. After that I'll add some support in the editor to assign sounds to bricks as well as the game support to play them. My graphics skills are still at an all-time low but I think I've found a friend who is capable of hooking me up with some textures. I'm holding out on screenies until I get something worthy of posting. That'll probably be after I put in some basic particle support and actually get the score and power-ups on the screen as well. ~S'Greth
  11. Nothin' huge tonight, but it's kinda nice to see results. I cooked up save/load logic for the editor. I also somehow managed to sneak in a good solid hour+ of guildwars. AND I'm getting to bed before 11 PM...remember I have a child who'll wake me up at 6:30, so 11 is pretty much the end of the road for me :P Now that I can create the basic 'shape' of a level, I'd like to move over to the actual game side of things and get the basics working over there. This involves -ball 'physics' -paddle input/movement -block collision detection -end of level detection -ball out-of-bounds detection After that's in place then I'll go back to the editor to add all the cool 'powerups' that actually make the game actually interesting :)
  12. Well, lots of Win32 fun this last weekend. "Why not MFC?", you ask. I hate dealing with MFC to be frank. I enjoy the simplicity of Win32. The most complex thing about it would be...well...nothing. This screenie just shows a basic block layout scheme along with the tool window. I forgot to checkin the boarder textures, but you can set those along with the background. Next up (I think tonight) I'm going to work on exporting and importing levels.
  13. I cooked up a little grid class last night. Here at work I fleshed out a list of items I need to start banging out for the editor. The first one was a little grid class to draw....well...a grid. It still needs a bit of tweaking, but I'd say it's about 80% done as of now. Oh yeah, and I have to document it too. As soon as I finish up with the grid work I'll port over my DirectInput wrappers so I can get mouse input going (and hit detection for block selection). That should carry me through tonight. I'm going to wait just a while longer before I post up a screenie. Something about a window with a grid just not being exactly awe-inspiring ;) I also am going to try and stay awake a bit later to try and bang out more code at nights. 1.5 hours a night just isn't enough to really make good progress IMHO. I'd rather have a good solid 2 to 3 hours. My son is usually in bed by 8 which means I can rampage to 11ish ad get a solid 3 hours in, assuming I'm not paying pennance with some wife-time :D ~S'Greth
  14. Thanks a bunch guys, I'll probably employ the periodic updates scheme, but I honestly odon't plan on having housands of particle counts. Remember, this is just a simple breakout clone :) I just don't wanna implement the particle system half-assedly so I have to re-code it again later. Thanks again!
  15. That makes complete sense. I wasn't really considering doing batches that large, but my concerns were mostly if there was a more efficient way of doing translation other than locking down the vertex buffer and trolling through it. It just seems like there must be a better way. It'll work for now though as my particle counts won't be terribly high at all.