Jump to content
  • Advertisement

SGreth

Member
  • Content Count

    291
  • Joined

  • Last visited

Community Reputation

218 Neutral

About SGreth

  • Rank
    Member

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. SGreth

    PhotoMonkee

    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 photomonkee; 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=#000000] Basic Tools Brush Scale/Rotate/Translate Magic Wand Text Eraser Pixel Selection (with additive and removal modes) Flood Fill Basic Shapes Canvas Zoom Color Picker Layering System Blending Opacity Styles (only drop-shadow so far) Canvas Cropping and Size Modification Color Palette system with support for RGB, HSL, HSV and CMYK color models Filters Color Inversion, Gray-scale, Sepia Brightness/Contrast Color Adjustments Sharpen, Emboss, Smooth (Convolution Filters) Jitter, Pixelate (displacement filters) 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!) 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. SGreth

    Particles!

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

    Level Backgrounds...check

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

    A little audio for breakfast

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

    More brick bouncing

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

    Save/Load

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

    The editor is born

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

    Ze Grid

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

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!