• Content count

  • Joined

  • Last visited

  • Days Won


JTippetts last won the day on July 15

JTippetts had the most liked content!

Community Reputation

12951 Excellent

1 Follower

About JTippetts

  • Rank

Personal Information

  • Interests

Recent Profile Visitors

50675 profile views
  1. Water

    I routinely pull from the latest Urho3D head (usually about every week or two) just to keep it up to date.
  2. I've used LuaBind before. Years ago, before it essentially died. Most of the clones or forks on github haven't seen a commit in 3 or 4 years. The Rasterbar repo hasn't seen a commit in at least that long. Plenty of time for that thing to rot, and it was never a very well-behaved library to begin with, at least in my experience. There are newer and much nicer (and far more actively developed) libraries to choose from now, such as sol2, Selene, lua-intf, Kaguya, etc... Many of them take advantage of C++11 and above, to eliminate the need for Boost dependencies. There is a fork of Luabind that eliminates the Boost dependency, and it has seen a small surge of recent commits in case you're interested. https://github.com/decimad/luabind-deboostified Other than that, I'd recommend going with a binding library that has more recent support, and an active community using it that can help in the case of weird errors.
  3. Medieval Story released

    Pretty awesome that you released it, man. I wouldn't let a couple bad reviews get you down. Of course, it's easy enough to say that, but fear of exactly that kind of criticism is what has kept me from releasing stuff in the past. People can be dicks.
  4. Gallery page is constantly expanding in size when I view it: It'll continue to infinity if I let it. Win10, Chrome browser.
  5. Please do not necro old posts.
  6. Water

    So, I ended up doing the "skirts" method I spoke of in the last post. And in conjunction with the default Urho3D water shader (with a few small tweaks, and more to come to eliminate artifacts on the corners of the water blocks) it actually looks pretty decent. The water animates a noise texture that ripples the ground beneath. It also uses a reflection texture (which I have set to black at the moment) if desired. I might tweak the water shader further, but for now I'm happy with it. I've also got all the small issues sorted out from the change to multi-level water. It wasn't a large change, but I was surprised at how many different parts of the code worked from the assumption that water was determined by elevation < 9. I thought I had contained it better than that, but I did get all the various spellcasting, pathfinding and object spawning oddities worked out.
  7. Multi-level Water

    This one doesn't have the overlap lines outlining the hexes.
  8. Multi-level Water

    @swiftcoder: Well, if I keep with a partially-transparent water, then I'll need something to be drawn underneath it, otherwise you'll just see the blackness that lies at the heart of the world (or, at least, the distance-based fog that lies beyond the stuff you can see). If I go with a solid water approach, then I would certainly eliminate the ground tile. @Krohm: I have no idea what that would entail, to be honest. I'm not really looking to do reflections, either; I'd prefer to keep to something a bit more cartoony, in keeping with the style I have established so far, and I'm not sure reflections would really fit. Even something as simple as a cycling animated texture showing water flow and ripples or something would probably be more appropriate. Trying out the options: I definitely prefer the partially transparent one, but that could just be the plainness of the non-textured primitive.
  9. Multi-level Water

    So, I'm trying to figure out how to do water. Right now, I am doing water the "brain dead" way; any tile below a certain height is water, and water is created as a simple hexagonal plane with a partially transparent blue material applied. It works okay, but the ultimate end goal is to have water play a more involved role in the landscape. I'd like to have rivers, waterfalls, etc... and that means that I need to rethink how I do it. I'm trying to come up with ideas for the geometry of water. Here is a shot of how the current water system might look if I use it unmodified for multi-level water: Clearly, I need some sort of geometry to tie the pieces together. My first thought is to create a sort of "skirt" piece that is attached to the side of a water hex if that water hex has neighbors whose water height is lower than its own. Might end up looking something like this: The issue with that, of course, is that I have to oversize the skirts to avoid Z-fighting with the underlying ground hex, and that means that skirt pieces overlap with adjacent skirt pieces on different hexes and with the water hex of the lower water levels. In combination with the alpha-blending, this creates bands or regions of darker color where two pieces of water blend together. I could use waterfall particle systems to help obscure this overlap, I think. Alternatively, I could use a solid material instead of a partially transparent one: I dont like the look of it, though. Large areas of flat water look terrible. Granted, there will need to be improvements to the actual water material to make it look better regardless of how I handle the geometry, but for now I'm sorta stuck on how best to do this. I do have some ideas as to how I could perform the geometry stitching of the skirts to minimize overlap, but it'll take the creation of special pieces, and some special-case code. Not too difficult, I suppose, but still seems kinda messy.
  10. New Gameplay Video

    The video quality actually turned out significantly better than I thought it would. Previewing the video in the media player, it kinda looked like hairy ass, but uploaded to youtube it looks pretty decent.
  11. Doors, Dungeons, MakeHuman, Bug Fixing

    Yeah, I think I might change that center panel to a lighter shade of wood. The door knocker is a good idea, too; I could just add one on each of the 6 faces.
  12. New Gameplay Video

    I'm on vacation in California, which means I kinda have some time to work on stuff, but it's split up by blocks of frantic activity. I'll tweak a few things, then head off to Knott's Berry Farm to burn in the sun while the kids ride on rides too small for me. Then I'll fiddle a few more things, then take the kids swimming. So while I'm getting some stuff done, it's all in a sort of disorganized tangle. I did decide to upload a new gameplay video. Once again, it's pretty poor quality. (Some day, I'll own a rig decent enough to make high-quality videos. But that day is not today.) It's about 10 minutes of random gameplay. I was kinda distracted while playing by a 5 year old who wanted my help building electronic circuits with a snap kit toy he recently got, so there are some pauses. Also, there is still stuttering in some spots, which won't be cured until I fully convert everything from Lua to C++. (That's an ongoing project, but I am getting quite a bit of progress done while here in Cali.) The stuttering is from the Lua garbage collector, which has been an ongoing problem with the Lua bindings to Urho3D. Throughout development of this game it has been at time worse and at times better. A recent change (unsure which one) made it worse again, enough that I'm finally going to just convert everything except UI stuff to C++ components.
  13. You haven't said much about your platform (and I don't know very much about HTML5 platforms in general) but if you have access to shader technology, you can often accomplish this kind of thing with quite decent performance. Just search at ShaderToy for star fields, and you can see stuff like this: https://www.shadertoy.com/view/XlfGRj Granted, deciphering what's going on in some shaders is kinda tough, but you ought to be able to at least pull out some things you can use to your own benefit.
  14. Find the bounds of isometric image

    I don't know that you'd need to go that far. I mean, yeah, if your main focus were on the tool to do this, rather than on getting a specific task done, then sure.... Spend a bunch of time on it. But writing some kind of advanced algorithm and training it with data sets... no, I don't think that would be a good use of your time if all you need to do is a few hundred sprites for a single game. That would almost certainly take longer than doing them all manually. My first thought would be to write a simple tool that, when executed in a given directory, would automatically iterate through each isometric sprite in the folder. It would open each sprite in turn, display it on screen overlaid on top of an annotated grid perhaps, then it would wait for my input. It seems like all you are doing is trying to determine a bounding box (rather than a more complex footprint that adheres to the shape of the sprite) so I would have it accept an input string where you key in the dimensions of the box as you perceive it from looking at the grid. Your brain could do the processing, and all you'd have to do is key in a sequence of numbers. It would use your input to write a bounding volume in a file corresponding to the sprite file, and move on to the next. It would be an extremely simple, brain-dead tool, but even with such a simple tool it's amazing how fast you could churn through several hundred sprites. A couple hours to write the tool, a couple hours to work your way through the sprites, and done. You don't have to spend very much time polishing the tool (odds are you won't use it again down the road, unless you do a sequel or something, and even then you can just try to prepare better by obtaining this information from the artist, or stipulating that the 3D files be provided so you can calculate it).
  15. Find the bounds of isometric image

    The issue with trying to extract that information from an image is that you have to somehow inform the algorithm of which parts of the image actually affect the footprint. The algorithm can't look at your example image and know that the tall part is a chimney; for all it knows, the tall part lays on the ground and thus affects the footprint, making the object occupy much more area on the back-side of the object where the chimney occludes, even though that area should be open and not affected by the footprint. When I was still working on isometric games, I always just did the bounds/occlusion/footprint calculation step directly from the geometry in the 3D file from which I rendered the object sprite. The 3D file contains all the information to determine exactly what the footprint of the object is. In the absence of the original 3D file, then you'll probably have to go with a more brute-force approach. You could probably ease this a bit by building some sort of tool that will allow you to associate a particular object with a rough shape. ie, you could say "this image is LIKE a cube of size XYZ", and build the footprint data from that rough shape. Provide some sort of "grammar" or tool to aggregate simple primitives for more complex shapes. ie, "this image is like a cube of size XYZ plus a box of size WUV located at MNO offset from original shape", etc... How you build this tool or grammar is entirely up to you, but ideally it would: 1) Not take as long to develop as manually determining the footprint of each image would take 2) Allow enough conciseness as to actually reduce the workload of creating each footprint, enough that the overall time savings offsets the time spent developing the tool. Give that you could iterate on such a tool for quite some time, there would need to be a LOT of images needing done to make it worthwhile.