Jump to content
  • Advertisement

Danie Clawson

  • Content Count

  • Joined

  • Last visited

Community Reputation

172 Neutral

About Danie Clawson

  • Rank
  1. I am in the process of writing a 2d isometric game from scratch, and I'd like to know how/if I can add lights and shadows. The code I have so far can be found here, but it should be enough to know that right now, the maps are simple 3d arrays of true/false values. Later I will have different block types, and I'd like to add slopes. Here is a shot of the environment:  If it were a single layer tilemap it would be straight forward. I can understand the simple raycasting in 2d that is required. However, given that my maps have multiple levels of height as well as caves/interiors, I don't really know where to start. Any advice or opinions would be greatly appreciated
  2. Danie Clawson

    Creating an isometric camera system

      Woa, that's way outside the scope of this project. Whatever I do for any feature additions like camera rotation, it will have to have an extremely low art requirement. I'm already stretching to imagine finishing the current art requirements by myself.    Well most of my portfolio since college was just recently lost when my laptop was stolen. And everything from college is just run-of-the-mill graphics design and illustration. So...Not going to embarrass myself any further by showing that off. Anyways, I have done pixel art in a hobbyist fashion, made a couple test games with RPG Maker/Game Maker/Etc when I was a kid and I did graphics for them.   But really though I'm not planning to do a lot of per-pixel hand drawings. It's all going to be vector illustrations with texture added. I was planning to write a bone-based 2d animation tweening system as well so I can further reduce the hand-drawing requirement. Plus a paperdoll system for characters. Also, I'm only doing 4-way character movement as opposed to the more aesthetic 8-way movement to reduce the number of angles for character art. I chose NE/NW/SE/SW instead of N/S/E/W directions because I can just draw NE/NW and flip them, reducing the perspectives I have to draw to just 2 for each character part. So I guess I'm just saying, while I can't prove I have any real ability for any of this I have done the research and prototypes and I do know I can make some sort of product, though it may not be aesthetically pleasing to everyone.
  3. Danie Clawson

    Creating an isometric camera system

    Well, actually, I am the artist for this project as well. My professional training is actually just in art and I'm learning the programming as I go. Of course, I don't really know any art terms regarding games, either, :[     I had looked into 2d array rotation previously, figuring that 90-degree rotations would be the easiest way to go. I think that I could probably pull off that on my own but I definitely want to do everything I can to keep the player from getting disoriented. I think this is roughly what you were saying in this quote but, I had thought that perhaps I might just increase the overdraw to roughly double the screen size, draw a frame, and then rotate that frame on the screen incrementally through the 90 degrees, then fade that frame into the next frame which is drawn properly with the new 90* perspective. Of course, I'd have to pause the gameplay for whatever the transition time was, so pretty much any other solution would probably work better for the flow of the game.    I will google around about this "intermediate isometric tiles," and see if I can find anything in the mean time, but can you elaborate on this point? Definitely seems more interesting.      Oh and here's the new JSFiddle with my progress on smooth-scroll/sub-block. You may see a few issues at the edges but it's just from JSFiddle's CSS Styles, it's working normally in the real build. You might also notice, I've refactored the whole thing a good bit so it's not a hideous mess.
  4. Danie Clawson

    Creating an isometric camera system

        Well, I plugged in a terrain algo I had already written, and I got rather poor results performance wise. It took over a second to render a frame sometimes. That said I've already worked out how to cull 90% of the extra tiles which is good enough for now, and gets it back to a playable rate. I think next I will work on smooth scrolling. ARPG+Minecraft is basically what I'm going for so I think sub-block movement will also be part of that work. I think I've got it pretty much handled, anyways. How can I do camera rotations? That has always been an important feature in my head, but I really have no idea how to alter my camera loops and offsets to do that....
  5. Danie Clawson

    Creating an isometric camera system

      That is excellent advice, and I have taken it. To good ends...Check the JSFiddle.    Obviously, I need to implement some sort of checking to see if a tile is covered by others. I need to know about all 3 face's coverage..How do I find that?   Are there any other ways I can improve this, other than sub-block movement?   When should I start on sub-block movement? Any recommendations as far as that goes?
  6. Danie Clawson

    Creating an isometric camera system

        Well, I've been working on this idea for about an hour now and I'm honestly not sure about this approach. There can only be like, roughly, max.a*2*max.b*2 tiles on screen at any time. However, i'll be doing max.a*2*max.b*2*world.depth iterations against the voxels, and then more checks to determine if they are visible....What would make more sense, to me, is to find the correlation between a, b, and x,y,z so that I can iterate over all a,b positions and simply grab the voxel which, having a matching x,y & a valid voxel, is the highest on z axis....I'm really bad at finding these types of correlations in the data though. I'll update later with my progress
  7. Danie Clawson

    Creating an isometric camera system

    *raises from the dead*   Okay, StarMire. I hope this is readable. There is still a lot of clean-up to be done, but I have working code. I am hoping, now, that you can walk me through fixing the iteration of the blocks vertically so that I don't draw really tall things off the top of the screen, and really tall things come into the bottom properly. I feel like sub-block movement shouldn't be too hard so we don't have to focus on that, at least for now.   Here's the important parts of what I've got: var testSize = {     x: Math.round((canvas.width-200)/terrainImg.width)*terrainImg.width,     y:  Math.round((canvas.height-200)/terrainImg.width)*terrainImg.width }; function screenPos(X,Y) {     return {         x: (X-Y)*(terrainImg.width/2),         y: (X+Y)*(terrainImg.width/4)     }; } function cameraDraw(position) {     ctx.clearRect(0,0,canvas.width,canvas.height);          var cen = {         a: position.x + position.y,         b: position.x - position.y     },         max = { //Use testSize instead of canvas size so we can see overdraw             a: Math.floor(testSize.y/(terrainImg.width/2)),              b: Math.floor(testSize.x/terrainImg.width)         },         startPos = {             x: (((cen.a - max.a) + (cen.b - max.b))/2),             y: (((cen.a - max.a) - (cen.b - max.b))/2)         },         offset = screenPos(startPos.x, startPos.y);          offset.x -= 100 - terrainImg.width/2;     offset.y -= 100 - terrainImg.width/4;          for(var z = 0; z < world.depth; z++) {         offset.z = (terrainImg.width/2)*z;                  for(var a = cen.a - max.a-1; a < cen.a + max.a+1; a++) {                         for(var b = cen.b - max.b; b < cen.b + max.b+1; b++) {                 if ((b&1) != (a&1))                     continue;                                   var x = (a+b)/2,                     y = (a-b)/2,                     sPos = screenPos(x,y);                                  sPos.x -= offset.x;                 sPos.y -= offset.y;                 sPos.y -= offset.z;                                  if(world.blocks[x][y][z]) {                     ctx.drawImage(terrainImg, sPos.x, sPos.y);                  }                                  if(x == position.x && y == position.y && position.z == z) {                     ctx.fillRect(sPos.x+terrainImg.width/2-5, sPos.y+terrainImg.width/4, 10, 20);                 }             }         }     } } As far as the issues I've had previously, everything is great. The camera position is always the exact center of the screen. As you can see in the JSFiddle there are still issues. Really tall structures go off the screen at the top, and are not visible as soon as they should be when scrolling in from the bottom.   Here's a pic of what I'm talking about, just to be clear. I imagine the solution is to use these a/b positions to relate to the tiles differently. They are not actual positions but potential screen positions, and things with a higher Z should just move into the next a/b tile up....I'm not sure how to do that. Any advice would be great, so sorry I let the topic die so long. I had to fight some serious burn out to get back into this.
  8. Well initially I thought that this would be the more straightforward approach as I will be using sprites for all the graphics, but I am willing to give that a shot. That said I'm completely new to graphics so I only understand a little bit about transforms for perspective. Can you recommend a starting point on that sort of routine? Should I just start with a tutorial over making a graphics engine using regular perspective? Anyways, I'd still like to see about fixing this method. I'm really not much of a math guy so I'm worried about going any further out of my depth.
  9. I need to correct my math for getting the initial drawing offsets on a 2d isometric camera rendering a tile map. This math is so...sensitive. As you can see in my code there are many separate calculations which fix individual problems associated with staggered grids and such. Many of the calcs affect each other, though! It's very hard to find the "sweet spot." What I've got going now mostly centers the "center tile" in the screen, at the right screen ratios, but it gets messed up quickly and easily.    You can check out a live demo of what I've got right here, but here's the main drawing function: function drawWorld(world, center) {   var iMax = Math.ceil(testSize.x/ts)*2,       jMax = Math.ceil(testSize.y/tq) + 1,              location = {         x: center.x - iMax/2,         y: center.y       };      ctx.save();   ctx.translate(-th,-tq);      for(var i = iMax; i >= 0; i--) {     for(var j =0; j < jMax; j++) {       if((i&1)!=(j&1)) {         continue;       }              var sX = i*th,           sY = j*tq,                      sgX = (i+j)/2,           sgY = (j-i)/2,                      gX = sgX+location.x,           gY = sgY+location.y;              ctx.fillStyle = getTileColor(gX,gY);              if(gX == center.x && gY == center.y) {         ctx.fillStyle = "orange";       }       else if(sgX==mousePos.x&&sgY==mousePos.y) {         ctx.fillStyle = "white";       }              drawTopFace({x:sX,y:sY});     }   }      ctx.restore(); } What am I doing wrong here??
  10. Danie Clawson

    Creating an isometric camera system

      See this 'Fiddle revision for confirmation on this. Working on your other points now. Also implemented testSize updating.
  11. I just wanted to let you know I think it's a great and inspiring thing you're doing here. Thank you! For anybody feeling "slow" or "behind the curve" on this stuff, you should try to appreciate any prior experience you may have! :) My background is in art and graphic design. I had a little bit of poor teaching on javascript when I started a similar path. I suppose I'm about a year and a half into it now and still have very little visual evidence, but I am proud of how far I have come. I think teaching yourself is actually the best way to go, if you have the time.
  12. Danie Clawson

    Creating an isometric camera system

    True StarMire all from scratch.    Okay so I'm not sure I've done any of this right but here is the solution I made. First, Ill put here the stripped-down drawing loop code. Note that I've removed all the "what a tile looks like" and debug-info code, so don't worry about world input var's use not bein shown //ts = 64 th = 32 tq = 16 function drawWorld(world, center) { var iMax = Math.ceil(testSize.x / ts) * 2, jMax = Math.ceil(testSize.y / tq) + 1, location = { x: center.x - iMax / 2, y: center.y }; ctx.translate(-th, -tq); for (var i = iMax; i >= 0; i--) { for (var j = 0; j < jMax; j++) { if ((i & 1) != (j & 1)) { continue; } var sX = i * th, sY = j * tq, sgX = (i + j) / 2, sgY = (j - i) / 2, gX = sgX + location.x, gY = sgY + location.y; drawTopFace({ x: sX, y: sY }); } } } This is, at least, producing a consistent overdraw and does not "under"-draw at any resolution.     The problem is finding the "center" in the layout. Currently, it's pretty close, as long as the screen is fairly close to a landscape-orientation style ratio.     Here's the live code on JSFiddle. Gotta love javascript, when you need outside input. I recommend checking that out because, as I said I did strip out a few things for this post, and it is actually semi-working. Tile picking is good and player movement in tile-size increments is also working. You can get a better feel for the offset issue.
  13. Danie Clawson

    Creating an isometric camera system

    Well I'm honestly not sure of the technically correct answer to that, let me try to explain better. Of course as I showed I have some 3D information in there, the separate layers of terrain. It's basically voxels. But it will all be represented by sprite blitting. No meshes.      Not sure what you mean here, but I do get this part: Though again I got lost on what happens when it passes the center of the tile?   As far as height variation, as I said, terrain data is stored as a 3d array like terrain[x][y][z] with each element being basically either: on and having a material type, or off and just being "open air", and all being same sized cubes. Like minecraft, but again, rendered in isometric perspective with sprite blitting. Thanks for trying to help I'm sorry if I seem really dense!   Edit: Trying to clarify a little further, here.  This first image is a good example of the geometry-side of it but I never want the player to see world edges like that (the world will be toroidally wrapped so if you walk to the top it starts drawing the bottom - already worked that out in top-down view). Here's a more style-appropriate image showing exactly the kind of output I'm looking for but it doesn't highlight the "voxel-like" nature of the data as much.  
  14. Okay I have a terrain with the structure: terrain[x][y][z], and I want to create an isometric camera system, using a grid approach.   Each element is assumed to be a cube, and it's default value will be 0 for air (1 for dirt, 2 for water, etc). This will allow for terrain of multiple heights, and also overhangs/caves. Player x,y,z should be converted to the exact center of the screen. This means there is sort of a hypothetical flat "view grid", with copies extending up and down to max and min elevation, respectively. I think this should work fine. It will allow me to use tricks like testing if there is "dirt" at z+1 to see if I need to render the top face of the current cube.   So that being said, What is the best way to establish this base "view grid?"   Some things to keep in mind: Screen size will does not have a set ratio Cube size does have a set ratio The player is not limited to cube-size movement increments, but instead can have an effective location of ex. terrain[0][0.1][0.5]. Therefore: The cubes will not always fill the screen exactly, and will need to be padded. This padding will need to be accounted for with screen offsets. The cubes will need to be offset by an additional small amount: the player's distance from the center of the closest one. I need to know the basic math, or a standard practical approach to this. Any help or thoughts would be greatly appreciated!     For clarification, I need the methods of getting the positions of the grey tiles in this image: [attachment=24167:ISOEXDRAW.png]   Notice how the player (blue) is off center to the tile, but is still center in the screen. These are hypothetical locations which are to be translated into world coordinates.
  • Advertisement

Important Information

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

GameDev.net 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!