Jump to content
  • Advertisement


  • Content Count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About master_clown

  • Rank

Personal Information

  • Role
  • Interests

Recent Profile Visitors

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

  1. The latter. For now there's no need to spend time on this question, until I experiment it myself. Probably, ortho projection solves everything
  2. My goal is to fix the game field in some position, so that when the screen size is changed, it only expanded/shrinked, but did not go anywhere else. How should I process this? Maybe I will use fixed coordinates indeed, but when it comes to transforming, those coordinates would be transformed with respect to the screen size?
  3. Ah, there are various parameters of projection... What I meant that time was that if the size parameters of projection are the same with the window size, a unit square ('unit' in the sense of scaling from my code snippet) will have the sides of 1 pixel. Though, as you said, those size parameters might be anything, but for now I'm not interested in other options
  4. Zakwayda, many thanks to you) I had it absolutely out of my head, the thought about orthographic projection :D. I was using the perspective one in 2D game for real :D. OK, I've already beheld the difference. Here, one unit is a pixel (right?), so now I can treat units how ever I want, afterwards just changing them with respect to the window size. I will conduct further experiments with this later, but now, I hope, the key's been found
  5. The former is inappropriate for the reason you've written yourself. The latter is, probably, the thing I'm looking for and about which the guys above were talking. I just don't understand how it should look in the code.
  6. Looks like I did not get the thing, so I'll elaborate a bit. As I said, the game is a copy of 'Battle city'. For now I'm writing the code of the game field drawing. It happens in such way: 1. The view matrix looks at the origin from the point (0.0, 0.0, 1.0) with 'up' direction as (0.0, 1.0, 0.0). 2. The game field is made up from tiny blocks which are drawn consecutively. The place of a block is defined by its model matrix: model = mat4(1.0f); model = glm::translate(model, Vec3f(i * BLOCK_SIZE, j * BLOCK_SIZE, 0.0f)); model = glm::scale(model, Vec3f(BLOCK_SIZE)); for [i,j] block. The coordinates of vertices of a block are (±0.5f, ±0.5f, 0.0f), i.e. it's a unit square. So after scaling it becomes a square with scaling factor BLOCK_SIZE side, correct? And does this mean that the center of a block is initially at the origin? Well, the main misunderstanding I have is about window resizing and the coordinate system I'm working in. The problem is notable in the attached photos. After window resizing (horizontally expanded) the square has moved (or it's just the viewport is making something) ans is fully visible. What I want is to fix the game field in some ratio relatively to the screen, so that it expanded as the windows does, but stays in its place. What kind of things I should do is unclear to me.
  7. SillyCow, the center of the screen is the origin, with respect to which I should build a model matrix?
  8. I'm making a simple 2D game — a copy of 'Battle City' — using OpenGL Core profile (to train the skill in it), and now I've come across a question, how should I handle an object coordinates and sizes. What kind of measure should I use for them? As I get it, that info is being put to the model matrix. But how can I place my objects to the exact positions I desire them to be in? And how scale them properly? For instance, I want to draw a game field -- collection of little squares. The resolution of the screen may change, so fixed coordinates and sizes are inappropriate (or not?). Maybe then I should set numbers relatively the width and height of the screen? I hope I expressed myself clearly. It's quite a basic problem, everyone who made a game has faced with it. Though, can't get, what coordinates and sizes in what coordinate system to use when it comes to placing and scaling game objects.
  9. Folks, thank you all for your answers, they reassured me)
  10. The main reason I can't write even a simplest game is the problem in the title. In my vision, I should separate the information related to the game (score of a player, a nickname etc) and the information related to the rendering (mesh info, drawing method), which is done, for example, by creating a separate classes (there are other ways of doing so). Due to this, I'm always trying to do in that way, with no result, as you can see. Eventually, a design problem occurs. Namely, how I am to link those things between each other, if I ever have to separate them at all? If you have experience in making completed (operational, finished, not abandoned in the middle of development) games, tell me, how did you design rendering of game objects? I assume object-oriented programming language is used (C++ in my case). Well, it's not exactly an OpenGL problem described above. I'm just using its functionality and think in terms of vertex buffers, shaders and all that GL specific stuff.
  • 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!