• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.

manderin87

Members
  • Content count

    22
  • Joined

  • Last visited

Community Reputation

130 Neutral

About manderin87

  • Rank
    Member
  1. My first game to be released on google play. The game is only available on tablets due to higher screen space required, however I am looking into making a version for phones. Description An asteroids - like game in which you destroy asteroids and survive for as long as you can. You control a gunship and collect power ups and survive wave after wave of asteroids coming from every direction in space. Explode asteroids in brilliant color and crystal shards. Can you survive the onslaught? Avaliable here https://play.google.com/store/apps/details?id=com.projects.astroblasterdemo Thanks
  2. Ive rechecked everything... The rotation code was the problem.... I made two lists to keep track of the points... the original points and the rotated points. Both were pointing to the same object, i thought they were seperate, but they were not... so I just made both lists create a new point when adding to the list. The rotation is now correct. Here is the polygon constructor [CODE] public Polygon(Point... points) { if(points.length < 3) { throw new IllegalArgumentException("polygons must contain at least 3 points."); } for(Point p : points) { mRotatedPoints.add(new Point(p)); mOriginalPoints.add(new Point(p)); } } [/CODE] And the rotation code. [CODE] public void rotate(float x0, float y0, float degree) { for(int i = 0; i < mOriginalPoints.size(); i++) { Point point = mOriginalPoints.get(i); float x = (float) (x0 + (point.x - x0) * Math.cos(Utilities.toRadians(degree)) - (point.y - y0) * Math.sin(Utilities.toRadians(degree))); float y = (float) (y0 + (point.x - x0) * Math.sin(Utilities.toRadians(degree)) + (point.y - y0) * Math.cos(Utilities.toRadians(degree))); Point p = mRotatedPoints.get(i); p.x = x; p.y = y; } [/CODE] thanks everyone for the help and forgive my idiocy for not noticing they were they same instead of being seperate.
  3. [quote name='Khatharr' timestamp='1354244657' post='5005545'] while(mDegree >= 360) {mDegree -= 360;} while(mDegree < 0) {mDegree += 360;} [/quote] Didnt fix it. I know it has to be something wrong with the polygone rotation, its not working correctly. Ive stared at it for hours and i dont know what the problem is. Ive checked several places and the algorithm seems to be correct, but its not rotating correctly.
  4. [quote name='Khatharr' timestamp='1354244436' post='5005544'] Does SpriteBatch::draw() want degrees or radians? [/quote] Degrees
  5. Its the same thing... my Utilities.toRadians() calls Math.toRadians()
  6. This method is better for fixing the degree but it didnt change the behavior that I am experiencing [CODE] if(mDegree >= 360) { mDegree -= 360; } else if(mDegree < 0) { mDegree += 360; } [/CODE]
  7. the draw method i use is above, but spritebatch deffinitely uses degrees its located here [url="https://github.com/libgdx/libgdx/blob/master/gdx/src/com/badlogic/gdx/graphics/g2d/SpriteBatch.java"]https://github.com/libgdx/libgdx/blob/master/gdx/src/com/badlogic/gdx/graphics/g2d/SpriteBatch.java[/url]
  8. They both recieve the same mDegree value. Could it be something with the way i move the degree past 0? [CODE] if(mDegree > 360) { mDegree = 0; } else if(mDegree < 0) { mDegree = 360; } [/CODE]
  9. The polygon rotation method is [CODE] public void rotate(float x0, float y0, double angle) { Log.i("Polygon", "Degree: " + angle); for(int i = 0; i < mPoints.size(); i++) { Point point = mPoints.get(i); float x = (float) (x0 + (point.x - x0) * Math.cos(Utilities.toRadians(angle)) - (point.y - y0) * Math.sin(Utilities.toRadians(angle))); float y = (float) (y0 + (point.x - x0) * Math.sin(Utilities.toRadians(angle)) + (point.y - y0) * Math.cos(Utilities.toRadians(angle))); point.x = x; point.y = y; } } [/CODE] The sprite rotation is done through a libgdx spritebatch and I am certain its correct. [CODE] public void draw(SpriteBatch batch, float x, float y, float degree) { batch.draw(mImage, x - width() / 2, y - height() / 2, pivotX(), pivotY(), width(), height(), mScale, mScale, degree, 0, 0, (int) width(), (int) height(), false, false); } [/CODE] The delta time comes from libgdx and is the time since last frame. [CODE] float deltaTime = Gdx.graphics.getDeltaTime(); [/CODE] I am almost certain its something in the polygon rotation code... I was testing it... it would rotate until a certain point and then go the other way.
  10. There is something wrong with the polygon rotation method... I watched the degrees subtract and the polygon was still rotating the other way.. as the degree increased it went left as the degree decreased it still went left, instead of right.
  11. While trying to check, i made the rotation manual.... the polygon is still rotating faster. Its not the framerate, its the way the polygon is rotating using the polygon rotation method above or the method used to rotate the sprite.
  12. I dont know if it makes a difference but I am using libgdx to draw everything.
  13. I added to the rotate method [source lang="java"]mDegree += mRotationSpeed * deltaTime[/source] This fixed the polygon rotation a little, it doesnt rotate as fast as it did, but it still rotates much faster than the object.
  14. [quote name='BCullis' timestamp='1354214546' post='5005393'] In case my previous post got skipped, you DON'T WANT to establish a "per frame" rate, as you can't necessarily control the varying length of time it takes to process each frame. Ex: your player is facing a wall that takes up 95% of their view and isn't moving. That frame only takes 2ms to process. Then they turn around, facing 2000 props, 12 animated enemies, and dozens of particle streams. That frame takes 17ms to process. Your triangle would be spinning like crazy at the 2ms/frame, and then slow down considerably at the 17ms/frame. Rotate at a fixed time rate, not frame rate. That's why you want to use deltaTime, correctly, and why when you weren't bothering to use deltaTime it sped up and slowed down. [/quote] That certainly sounds like what is going on, should i just multply the rotation speed by the deltatime? The behaivor happened even when deltaTime wasnt there. [quote name='Álvaro' timestamp='1354215341' post='5005398'] I don't think it's an issue with the frame rate. The only suspicious part in how the code in the first post handles the frames is that there is a call to drawBounding() inside of the loop that updates the state, which seems wrong. Either the update happens independently of the drawing or --if update() is responsible for drawing-- the drawing should only happen once, at the end of the function. [/quote] The drawBounding() was relocated from the rendering loop so i could see if it had any effect. Its been moved back since, but the behaivor never changed.
  15. [quote name='Álvaro' timestamp='1354213068' post='5005386'] mDegree should be how much to rotate by this frame. It should not grow with time. What rotate() is doing is increase the rotation speed. EDIT: Wait... I think I see what the others are seeing now. Is it possible that mOrigins and mPoints are actually the same thing? FURTHER EDIT: What does this line do? [quote][code] Point npoint = mPoints.get(i);[/code][/quote] [/quote] There are two lists of points inside the polygon class. The original points mOrigin and the current points mPoints. mPoints changes and mOrigin does not with the rotation. That code takes the point i from mPoints and updates it. The rotate method just applies the .5f to increase the degree... The speed never increases, its always .5f and mDegree is increased by that amount each update.