Advertisement Jump to content
  • Advertisement


  • Content Count

  • Joined

  • Last visited

Community Reputation

466 Neutral

About ProPuke

  • Rank

Personal Information

  • Interests
  1. ProPuke

    An alternate graphical style?

    swiftCoder: Hmm.. Love is both a good & bad choice in my mind. I completely admire him for holding to his guns & really being able to say he created something that was his own, but the look is not without it's frustrations @ times. It's both an attraction & a deterrent, a USP & a deal breaker, a something.. & something not so good. Halo is a good example, I feel. It did a very good job of feeling fresh & nice, while not having to push too hard with any particular visual style (althou they did have a lot of bump-mapped metal panelling) Hmm.. universal styles are stale.. I'm not sure. Again, using classic Half-Life as an example of a game I really liked, looking back 1998 seemed like a pretty stale year, in terms of graphics. I remember 3D games around that era all tending to look very much the same. Yet I remember having this profound sense of fun & exciting story-involvement from Half-Life. This could be a tainted vision, of course, but perhaps one of the things that made it good _were_ that it was rather plain? (In as much as they were not a distraction & served their purpose very well?) To which you reply: "But no! Back then it looked most excellent! It was new & exciting then! Your modern expectations deceive you.". Hmm.. & maybe.. or maybe not? Just trying to see :] What are your thoughts? sunandshadow: an artistic choice, yes. But you don't need to be trying to make an artistic statement to make a game. (although if you are, all the better, right?) I'll agree that I also really like simple 2d styles. They're light on the eyes & give enough information, while not being too complicated or overwhelming. They compliment games, while letting you just get on with them & have fun. Even if done relatively simple as long as they're vector-like they will scale well. In comparison, if 3d models are done simply they're usually lower poly & don't scale well to scrutiny at all. (maybe part of the trick, as TyrianFin suggested, is in the toolset? We just need more organic modelling tools, heh) (Btw - I want you both to know I'm not disagreeing with you. I'm just trying to understand things from both sides. This thread is out of character for me & I'm glad I'm being chastised :]. The look is usually one of the first elements I like to get a firm grasp of when working on a project. I am, perhaps, trying to see things from another angle) Thanks for your thoughts so far, people. I think I'm starting to get swayed & lose momentum with my question already. Does anybody else have anything to say either way?
  2. ProPuke

    Drawing only what you need?

    Another minecraft-inspired game, eh? okay if you're calling a render() function for every cube this is absolutely not what you want to do. (if just because of the function overhead, alone. Do your processing inside the loop, instead) Okay, cubes have 6 faces.. So you want to make 6 lists of faces. Okay, go through each cube & only add a face to it's list if there isn't an adjacent cube touching that face. So this gives you all the possibly visible faces, sorted. (This is known as hidden face removal) You don't need to rebuild these lists every frame. Ideally you only need rebuild when the visible cubes change in any way. You might also want to sort them according to texture+shader. The reason being that you can set the texture+shader combination once then batch the whole face list directly off to the graphics card. You probably want to store this list as a vertex array for this reason. If you want to optimise further you could do so depending what quarter of the viewpoint the cube is in. When you're looking @ a cube you never see more than 3 faces @ once, so you can cut down that list of faces quite a bit, too. Each quarter of your viewpoint sees a different set of these 3 faces. For example, imagine you were looking forward: The top left quarter of your view can only see cube faces that face towards you, right or down The top left, towards you, left or down The bottom left, towards you right or up The bottom right, towards you left or up So for each quarter you need only render 3 of these face lists (but then you'd need 4 sets of these face lists, & need to decide which to place the cube faces in when you loop over. This also means you need to regenerate these lists when moving/turning which may not be optimal) This would give you frustum culling. (While you were checking you would also want to discard faces that were behind you) In this case the fact that the world is grid based means you can do hidden face removal & frustum culling (of cubes & faces) much faster than you would with normal polygonal data. With even just the hidden face removal you should have considerably reduced the amount of work you're doing to render it all. If that's not enough you might then want to look @ spacial partitioning methods to calculate what's visible (combined with the above) Octrees are perhaps an option. Spacial hashing is another one (a very easy-to-implement one imo. But maybe not as optimal in this scenario) (If you want to know about spacial hashing I can elaborate)
  3. ProPuke

    An alternate graphical style?

    Mmm.. The game examples were good. All nice 2d games, thou. But that's alright :] (Truth be told despite mentioning 3d games I much prefer 2d styles) Cell shading's also a good idea, & is reasonably easy to implement. It goes nicely with flatter, simpler texturing, too. Thanks. Khaiy: I was trying to avoid deliberately being stylistic for the sake of it. This is kind of an open question & my train of thought was: "What if someone really wants to make a specific game, but they don't want to push on any particular graphical style as a "gimmick"; They're interested purely in making the game?" That's what I meant by "pushing" for a style: trying to be overly stylistic. Maybe you're right & pushing for a graphical style is as important as any other aspects of the game. You make a good point in that you certainly don't want to make it seem like the graphics are "lacking" in any amount - as this may drag down the game. (which was my main initial fear)
  4. A possible option might be doing the reverse - you could memory map the files (a good technique if you are not familiar. Look it up) & pass them in everywhere as data. (You could create a memory-mapped file class that had a operator const char*()const. Might even see some performance benefits)
  5. Hi guys. Been a while since I've been on these forums. Aaand I'm posting outside the programming forums :D (although I did consider putting this in the graphical programming one) Lets talk about graphical styles in gamesWe're @ a point in time now when realistic looking games can look incredibly polished. I mean today's machines are games are capable of some pretty impressive stuff. But this can be a barrier if you're making games yourself & don't have teams of concept artists, modellers, textures, animators, graphical programmers & all the rest.. It seems that, in part caused by this, indie games are starting to pursue lots of unique styles of their own (& I'm sure also because some people are just awesome creative) But the days are gone when low poly models will do it any more. And most of us don't have the skills required to keep up with this hyper-realism style. Now I'm not saying that we should feel we have to; there are many different styles we can go for. But it seems any style we do go for we really have to seem like we're "pushing" for that style. If we do a game in any way "retro" it has to seem like we're really going for that retro style. It seems every style has to be hyped up in some way... And the question is...But what about those of us that just want to make games? Is there a good style that's applicable to modern 3d games but isn't too intensive to pull off? (cos we'd feel all self-conscious if we brought out a game that looked like classic Half-Life now, right?) Are there any simpler-styled games you like? How can we best avoid the problem of having lower quality textures & models? Games like minecraft get around this great. But the problem is that that's been done now, & it feels like a deliberate style and also going down that route would seem too "copy-cat". It would also seem like we were really "pushing" hard for that style, not just trying to make a game without making it look amazing. What do you guys think? Do you get me, or am I just talking rubbish? Am I totally wrong?
  6. ProPuke

    Reflection - one pass approach?

    To directly answer your question - maybe. But I can't think of any ingenious way of doing it. What's the slowdown from re-rendering the scene? If it's polygon or shader complexity then you could render @ a lower lod or skip some details (simplify your lighting to skip specularity & any bump/offset mapping etc). If it's scene generation then I'd advise generating & storing in vertex arrays, @ least for the frame & reflection, but really you shouldn't be regenerating anything that's changing anyway. A quick, alternative cheat might be to generate & periodically update a cubemap for use as the reflection. Obviously you'd lose out on quality, and it's not a suitable solution if there's a lot of dynamic content moving. But if you can get away with a lower resolution reflection, & don't have to update it often it may be suitable.
  7. ProPuke

    Opengl and Scenes

    Sorry Munro. It's hard to gauge where people are. Normally when you have a "scene" you define some way of storing or representing that scene so that your game can loop through and handle all of that content for you. You don't use individual lines of code to handle every item, but rather you create a system, with code, that handles that repetition for you. It's a slightly higher level of thinking. Rather than writing code that immediately performs the action you want, you write a system that can create & manage it. (If I am interpreting you correctly) When you mentioned loading models & using OpenGL we probably presumed you had written your own rendering engine for such things, & had a higher level of understanding. We were looking for something too complex. Couldn't see the wood through the trees :] Normally you would create a custom class to represent the model object & it's current state, & store the scene as an array/list of these items. Handling things like drawing would be a case of a section of code that looped through that list, & drew the corresponding item according to the state stored. (rather than a line of code for each) Often these scenes are loaded from another file (usually as maps/levels/scenarios). These scenes, complete with objects etc, are usually managed from editing tools. Sometimes we make our own to do this, sometimes we will use existing map editors or tools. We may not be able to help you yet because you may not fully grasp the vocabulary and concepts involved. (we can't tell you how to write a haiku before you learn japanese) Keep studying. Maybe look at some more general programming material before you delve deeply into gl. There are some other skills required for making games too :]
  8. The targa format is a simple one & only offers simplistic rle (compresses adjacently repeated colours) compression at best. It has the advantages that it can store an alpha channel & is very simple to read. But that's about it, really :] png out-performs it in every other way (and also stores an alpha channel). Being such a simple format it does seem odd that support would not be included, or even dropped. But it doesn't really serve much of a purpose any more
  9. ProPuke

    Faster/manual ChoosePixelFormat

    Brief tests seem to indicate that (@ least in windows 7 under the latest nvidia drivers) all information is fetched & cached upon the first call to any *PixelFormat function. No further substantial delays occur after this first call. This, however, means that manually enumerating through the modes is no faster (again, the first call blocks [for several hundred or thousand ms], & later calls execute "fast") I guess I can move detection across to a parallel thread on startup (so it does not stall non-dependant elements) & cache the result for systems that do not; but I'd still like to alleviate the delay all together, if any one has any ideas? Oh well, thanks anyway guys
  10. ProPuke

    Faster/manual ChoosePixelFormat

    Thanks for the responses so far guys. Sources online seem to indicate wglChoosePixelFormat is a system function used internally by ChoosePixelFormat & should not be called directly. (t may be unsafe to do so, or not always return reliable results) Thanks, too, mhagain, but changing the pixel format requirements don't seem to make any difference to the time from here, either (although it was a nice suggestion) I'm gonna have a look through Microsoft's GLEnum & see if I can narrow down the cause & step around it (I don't see why querying pixel formats should take so long, I suspect there may be some "virtual" devices causing foul-play) But once again - any thoughts from people who may have experience with this would be very much appreciated. Thank you. ps: I'm not sure I really have a specific preference. I'm a simple kinda guy, maybe I need to broaden my waffling horizons
  11. While looking @ trimming down my initialisation code I've noticed ChoosePixelFormat blocks for between 0.5 & 2 seconds when called. Could anyone offer any advice on selecting pixel format manually, or skipping non-essential (internal) lookups that may be causing the pause? ps: I like waffles [Edited by - ProPuke on July 2, 2010 6:48:15 PM]
  12. ProPuke

    Advice on making a dating sim

    Quote:Original post by Kwizatz Seems you're thinking about hard coding your dialog, don't. Instead write code that reads text formatted in such a way as to keep the flow of your game, for example you could use XML. Actually Kwizatz could be right there. I'm perhaps a bit overly keen on embedding code :P Take what I said last of all with a pinch of salt & find the mix that works best for you.
  13. ProPuke

    Advice on making a dating sim

    Hmm.. An intriguing genre. Not played many dating sims (well, only played a few mini doujin shoujos) I know you weren't looking for coding suggestions, but have you looked into Ren'Py? I've not used it, but I know Katawa Shoujo is being made in it; & since it was designed for graphic novels it may be worth trying it out, or just going over the docs & examples to get an idea of how that kind of code is structured. Off the top of my head this is how I'd probably lay it out: (my terminology and stuff is probably totally wrong - I apologise) I'd probably manage the game using 2 key elements - story arcs, & weights: A story arc would be (as you described in the case of a scenario marker) the stage you were in the game. Each arc would have its own section of code, & would end by switching to one of several other possible arcs. For instance: You might have the "intro" arc, would can end with either the "cafe" or "school" arc. Of course you wouldn't want _too_ many, & there's nothing to say that sub arcs can't rejoin back to main story arcs again (infact they should). I'd split each story arc into a separate file, & draw out a biig diagram to map out the different ways the story could go. I would also have "weights" - would could be your emotional standing with the different characters in the game, or rankings in certain areas. Within a story arc different lines could be read depending on your standing with that character (although the basic layout of the story would remain more-or-less the same), & possibly affect which further story arc you end up with. Decisions within story arcs which lead to different paths would still be kept within the same arc. I would just use temporary variables to keep track of roughly where you are in that arc. Arcs would be mostly linear, but with varying sets of lines within, & but the decisions you make inside them would affect your weights, & the eventual destination arc you end up in. Obviously you'd want a pattern which doesn't get your code too complicated. I noticed you gave the example of using literal numbers as your scenarios. I'm not sure if this was just you simplifying, or was a thought-trend based on the language you were using. In C++ I would use classes for different story arcs, that inherit a base interface. Each story arc class could customise a virtual run() or update() method with different code. When the arc was due to change I would use something similar to: if(day_has_ended){ game->arc=new storyarc::Day_2(game); delete this; return; } Upon each update loop of the game object it would run the virtual method in the attached arc property. I would leave arcs responsible for deallocating themselves & allocating new arcs in replacement (it is safe to do as long as you are certain about when access to objects cease). Apologies if I went off track on that last bit (that may not be familiar territory for you). But I totally wish you the best, & would love to be updated on the status if this project takes off. (also if you want any technical advice & feel I could be of help)
  14. ProPuke

    Server Responsibilities?

    My approach is the following: I have 3 sections of code - the server, the client, and the gamecode The gamecode is in charge of simulating & managing the world. It might be better to look at it as a game Object - an instance of the world A server contains a game object Clients also contain game objects The game's for the most part appear to run seperately between the two The clients periodically send updates about their own states to the server (player position & input states) The server periodically sends relevant updates about the surrounding world to related clients (for instance, nearby objects etc) The clients receive these updates, update their game model (sometimes with tweening or prediction to "slide" into this new state), & continue to run the simulation When an event occurs in gamecode that is classified as important (damage taken, player killed, end of match etc) then the game checks to see if it running on a server or client module. If it's running on a client it gets disregarded If it's running on a server, then it's processed forwarded onto clients to process Since the simulation is occurring both ends responsibility can be shuffled between the server & client by simply controlling what is classified as an important issue It is also up to the server to verify that updates received from the clients are valid, thou. In an ideal world you'd use fixed timesteps & simply send input state changes to the server, with time stamps, & the server would forward predict game states for the player from there (the quake 3 network model does something similar), but usually you can get away with sending player positions (& having the server preform sanity checks on them) & current input states so the clients can continue to predict. I think this kind of model is fairly common. In short - things like projectile motions are managed by the server (since they would be triggered by the important "player fires rocket" events), but they continue to be simulated by the clients once the clients place them in their game models. However - the server continues to correct these predictions, & handles the important details like when it explodes & the damage dealt Sorry if I was a little unclear, I typed this all in somewhat of a rush. If there was anything there you couldn't make out - feel free to ask me about it & I'll respond with better thought out detail when I get home from work
  15. To elaborate a bit more on the switch to premultiplied alpha: I have some bilinear rendering artifacts atm: I have bright, low opacity pixels next to dark, high opacity ones, & am getting bright halos on the transition. This isn't a case of incorrectly cut graphics - Both of the colours are needed that way. This is a side affect of opengl bilinear filtering sampling the texture first, and then blending with destination (in the case of pma the alpha scaling has already been performed so this does not occur) I will also be compositing translucent render targets in the future I am using GL_POINT/LINE/POLYGON_SMOOTH, yes I see no evidence to suggest it is deprecated or advised against (again, if this is incorrect please advise) You are probably correct, thou I will have to drop use of ff smoothing & settle on multisampling or specialist shaders Does anyone else have anything further to contribute? :/
  • Advertisement

Important Information

By using, you agree to our community Guidelines, Terms of Use, and Privacy Policy. is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!