Jump to content
  • Advertisement

lawnjelly

Member
  • Content Count

    706
  • Joined

  • Last visited

  • Days Won

    15

lawnjelly last won the day on October 28

lawnjelly had the most liked content!

Community Reputation

1720 Excellent

7 Followers

About lawnjelly

Personal Information

Social

  • Github
    lawnjelly

Recent Profile Visitors

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

  1. lawnjelly

    Frogger - challenging entry

    There are some other export options for Godot: Android, MacOSX, iOS, Windows Universal, HTML5. I am keen to get Android working if possible as I've mostly built it with mobile in mind although this will be after the challenge I think. Yup it has lots more advanced stuff (PBR, HDR, bokeh etc) but I am always thinking in terms of mobile so try and use simple shaders, low shadow resolution / overdraw etc. I did some testing last night and it runs about 350-500 fps on my PC. The packaging / export process is very easy and quick.
  2. lawnjelly

    Frogger - Post Mortem

    Finally made a first release of my frogger game for the gamedev challenge yesterday: What went right Using Godot Engine. Godot and GDScript was very quick to learn and get started with, and is very good for these types of small scale games. Overall I preferred it to Unity which I used last challenge. Using skin modifier for modelling in blender. This enabled me to make game creature models fast, around a day for modelling, rigging, animating and texturing a model. Using 3d paint for texturing creatures. Having spent many months developing 3d paint, it is really starting to pay off in quick texturing of assets. Blender can do this texturing too, but the workflow is much faster in 3d paint. What went wrong 3d sound broken in Godot. I had to do some bodging to get any kind of positional sound working, and it is flakey at best. I hope they will fix this soon. Android support not yet working. My android hardware / emulator only seem to support OpenGL ES 2, and Godot only supports ES 3, up until the 3.1 release. I tried the 3.1 alpha but no joy as yet. Creating art assets took most of my time, approx 2/3 of the development time (I am not an artist!). Moving house - I only realistically had the first 3 weeks to work a lot on the game, so tried to finish as much as possible early up. I do not even have access to computer / internet at new house yet. Dealing with different aspect ratios. I don't really deal with this as yet, I may have to address this. Normal mapping the assets. I tried this on the cars but it is very finicky to get working right and I don't have much experience. Took a lot of time and the difference was negligable so I dropped it. Procedural terrain texturing. Implemented but was too slow in GDScript, so I precreated 5 terrain textures and just used them in the levels. Same algorithm was fast enough in Unity in C# so I think GDScript is several times slower currently. (However I do prefer the GDScript language to C#) No wheels on cars. This is just funny, I always intended to put them in but never got round to it!! Dropping lots of features due to lack of time. This is typical of gamedev in general, but luckily I had enough features to make it playable. There is already support for other pickups like score and poison etc, I just didn't have time to make the models.
  3. lawnjelly

    Frogger - challenging entry

    Thanks Rutin, I was worried slightly that it was even running for other people, you are the first that has tried it! I can now complete it each time, takes about 15 mins, but I will put in some more levels. It would be nice to put in difficulty options and game modes like I did with Tower Defence.
  4. Whether you need to add any padding depends on whether you are planning on using mipmapping / filtering. If you are using pixel perfect sprites there is no need (providing you line everything up correctly). Typically for a 2d game like this you want to separate your engine into rendering static elements and dynamic elements. Static elements of a map might be stuff like floors, walls, things that never change. For static stuff, you can put it all in one vertex buffer with a static usage flag. For dynamic, put it all in one* dynamic vertex buffer with dynamic usage flag. *You might also want to use 3 mirror dynamic buffers and use them alternately in a circular order 1, 2, 3, 1, 2, 3 etc, this ensures that you can write to a buffer while the previous one is still being used for rendering in a previous frame and prevents a pipeline stall. There also may be various variations of this to make things even more optimal, but the basic idea is the same. I believe unity does this kind of batching for you behind the scenes. To actually draw the elements using a vertex buffer is simple, typically just a list of quads with unique tex coords per corner. This way you can swap the tile used on any quad by simply changing the tex coords. You can base the whole background as a bunch of quads on a grid (this is what many people do), you don't need to of course. But if you do, you can render e.g. a long thin part of the tile map as several tiles instead of one. GPUs are so fast these days that they will eat through these tiles, there is no real benefit to rendering different shaped as 'one quad' rather than e.g. 4, and this makes the map editing etc much simpler to code. To change the dynamic elements on each frame, lock the vertex buffer, then copy across the new tex coords / vertex data, as many as required, then render this many quads. Of course there are more advanced schemes but this should enable you to get started in the fashion of a lot of top down 2d games. You may also end up batching different parts of your vertex buffer and rendering the parts with a different shader. e.g. 0-100 normal, 101-150 transparent, 151-280 additive etc. Overall there will only be a few draw calls which is optimal. Often you can also get creative with the vertex format / uvs. If for example your texture atlas is on a regular grid, you might e.g. only need to send one integer for uv, and calculate the uvs in the shader.
  5. lawnjelly

    Cinematic Insanity

    Looks fantastic, very stylish! I don't know if it is a good way, but I just animated frog jumping on the spot, and for each jump I calculate a new target position fixed distance away, then move the frog towards this target position in code. The frog thus mostly moves on a 'grid' but when it moves on a log or something it gets taken off the x grid a little.
  6. Here is my first build of my frogger game for the challenge (make sure to download the game rather than assets pack): After starting early last month I've been put on hold most of this month due to attempting to move house, so I've had to severely cutback the features, but I have managed to pull things together to make something playable. Still lots I'd like to do to improve once I have some more time on my hands. I spent today putting together 14 or so levels, it should be reasonably challenging, and enough to spend 20 mins or so on, I can complete it. Let me know if it runs okay, there are Linux64 and Win32 builds. I tried making an Android build with Godot 3.1 Alpha but no luck so far, it crashes on running, maybe I can change some settings in Godot and get it to run. Also the sound is a bit broken, the 3D listener is broken in Godot 3 currently so I had to bodge some 2D sound until they fix it. Cursors to move and TAB changes camera view. Incidentally, though the game is usually easier in top down view you can theoretically complete it all in closeup view, if you want a real challenge!
  7. After spending many hours painstakingly attempting to model creatures entirely by hand, I finally discovered (a couple of years ago) the skin modifier in Blender, which is a fantastic quick way to build organic creatures and shapes, especially for the artistically challenged like myself, and also makes rigging a breeze. I thought I would write a quick description for those unfamiliar. If you want ultimate control, particularly for a low poly creature, there is no substitute for manually creating polys. However, this can be very time consuming and tedious. If you are instead in a position where you are willing to trade off speed of creation against 'perfect rendering efficiency', or are making medium/high poly models, or models for later sculpting, then one of the options available is the skin modifier. Using the skin modifier, instead of modelling the skin by hand you place the joints (as vertices) of a creature to build a kind of skeleton, and allow the skin modifier to automagically generate a skin around this skeleton. Process Typically I start off by creating a plane, then go into edit mode, and merge the vertices to 1 in the centre. Next set up the modifier stack to create the skin. At the top of the stack goes a mirror modifier, because most animals are symmetrical bilaterally. Next goes the skin modifier, which creates a simple box-like skin around the skeleton. Finally add a subsurface modifier to smooth the skin, and make it more organic. Once the modifier stack is ready you can begin modelling. In the case of this bird, I started with a top-down view. Select the start vertex (there should now be a 'blob' around the single merged vertex), and create the skeleton by pressing 'e' to extrude and place a new vertex. I did this to place several vertices to create a backbone for the bird. You can then create wings and legs by picking one of the vertices in the backbone and extruding to the side. If you follow this process you can form a rough top-down skeleton, it doesn't have to be exact because it is easy to adjust, that is one of the beauties of skin modifier. I find it useful to google pictures of the skeleton of the animal for reference. Next look at side views and adjust the up-down position of the vertices (joints). The legs needed to be going downwards, and the head slightly up. Once I am happy with the basics of the structure, I start to fill it out. You do this by selecting a vertex, then pressing 'ctrl-a' then dragging with the mouse. You can make the skin thicker or thinner at each vertex. This can quickly give you a reasonable shape. You can further refine the shape by pressing 'ctrl-a' then limiting to either the x or y axis by pressing 'x' or 'y' before dragging. I used this to give a broad flat tail and wings. Conclusion Pretty soon you can build a pretty good model. You can tweak a few things in the skin modifier, especially set a root vertex (e.g. pelvis) can make it easier for later animation. Skin modifier also makes rigging easy. Once you are happy with your skeleton, make a copy of the whole thing (so you don't lose the original), then choose 'create armature' from the skin modifier. This will create an armature and link it to the mesh so it is ready for posing and animating! I also typically choose smooth shading in the skin modifier, then manually add hard edges in mesh edit mode (ctrl-e, hard edge, and use in combination with the edge-split modifier). I also use this to select seams for uv mapping. Note that once I finish the skin modifier version I usually have to do a little tweaking of the polys manually, because there are some things it is not good at. Anyway, this has been a brief introduction to this method, I would encourage trying it and following some youtube tutorials. After some decimating and very rough texturing (~640 tris)
  8. lawnjelly

    Frogger Challenge Entry

    I just tried it it runs great under wine! Haha is so similar to my 3d one but I guess we are both starting with the classic gameplay. Old school sound effects work great (better than the sounds I have so far in fact). I found it very difficult to get the frog in the exact right place for the home at the top, takes some practice!
  9. lawnjelly

    D3D9 Render to Texture Problem

    Now reading this makes me not so sure of my first answer, (it may not even be necessary to have multiple copies of render texture if it is getting used immediately on that frame, thinking about it, it is more commonly an issue for things that are uploaded like vertex buffers). If the problem was with the dynamic usage you would think it would be more likely to write to the texture correctly at least the first time. Usually I would try and approach such a problem methodically and eliminate the possibilities. I would start by rendering to the texture and only saving it to a file, and not attempting to draw to screen. If this works ok then it suggests the problem is due to the dynamic usage. If saving it to a file doesn't work then it maybe something with the setup of the render target. It is almost like it is writing to e.g. z buffer first time you draw and all further draws are failing. Sorry can't help more. Z buffer setup can be an issue it seems: https://www.gamedev.net/forums/topic/607511-render-target-z-buffer-problem/
  10. lawnjelly

    D3D9 Render to Texture Problem

    I have not read in great detail, but could it be the problem is being caused by the double / triple buffering problem? I.e. are you are trying to render to the texture when the old version still hasn't been drawn out to the screen, in which case what is the graphics to do? This is the same reason why you need another duplicate of the frame buffer in memory for double buffering. So I would double check your usage flags, or try manually implementing round robin 2 or 3 textures (or copy to secondary texture from frame buffer texture?). I haven't used directx for a while so maybe someone can help more precisely.
  11. lawnjelly

    Hopper ( GameDev Challenge Entry ) Blog 01

    These box models and maps are looking great Dexter!
  12. Assuming I understand your question correctly, it is not just running the game, it's running the tools for making a game, so you'd have to use something that worked well with low resources / ARM processor. For programming you can at the most basic usually use a simple text editor if you had to, so you could probably use a compiled language (e.g. c++) and use a low level API (e.g. OpenGL, SDL etc), or try a higher level / interpreted language e.g. python, simple engines, an html 5 game (although you'd have to check performance on html5 in browser). You would have to forget about running most big 'engines' though I would imagine, both because of finding builds and them not running well on the hardware (although it seems you can run early Godot verions). Making assets on a Pi might be another story (graphics editors etc). Although it does seem to be able to run blender(!!) on Pi (although I wouldn't recommend it): https://blender.stackexchange.com/questions/77574/blender-build-for-raspberry-pi3 Having said that, I've never used a Pi, and bear in mind standard practice when developing for lower power machines / consoles is to do the actual development on a more powerful / versatile machine, then test / debug on the target. However if it is all you have available or you want to limit yourself, I'm sure you can do a lot, and you can certainly learn a lot, many older games were developed with less powerful machines.
  13. Recommendations will depend on what exactly the application is, how big it is, what it does, what percentage is graphics / other code etc, application is rather a vague term. Just as a heads up, there is no need to use much java on android, you can use it just as a thin layer to call your c++ code compiled with NDK, or you may be able to go native completely and have no java code. c++ then is cross platform and you can have an android / PC / iOS build.
  14. lawnjelly

    Concept

    Keep going you guys! Just a heads up, if I'm quiet on the progress / forum it's because I'm moving house to Wales! Figured the welsh game development scene could do with a boost. Got to move all my stuff across, get broadband sorted, get a plumber to fix a leak in the attic, get a stuntman to fix a loose antenna, get heating oil delivered etc etc, and all 2 hours ride away on the motorbike in winter, so it will be a wonder if I get much frogging done, but hope to have a basic version working by the end, although not as many bells and whistles as I'd like.
  15. Sure, as long as you make sure you are not accumulating any e.g. float error.
  • 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!