Java Beginner.
Hi, I haven't got any much experience with GUI programming. So I'm after some hints on how to tackle this next project. Hopefully I can explain myself well enough.
(source: mobilehomeservicesltd.com)
(see above photo as a reference)
This GUI aspect of my program will be a 2D - Birds-eye-view of a static caravan and veranda/balcony made with basic shapes. So typically the caravan will be represented by a rectangle (just a rectangle, ignore the fill in diagram). Sometimes static caravans have shaped fronts so that would be represented by a polygon as opposed to a rectangle. All in scale dependant on the users input, as all caravans have their individual dimensions.
After the caravan unit is in place I then need to draw another polygon surrounding the caravan representing the balcony/veranda, all to scale. Understand so far?? Good. Here comes the challenge part (for me anyway).
On the polygon representing the balcony I need to be able to draw lines to represent the decking that will be nailed down as a surface (like the diagram above). Now because the caravan could possibly have a shaped front, the decking must follow the shape of the caravan. In other words, if the caravan has an oval or angled front the decking will have to be cut to follow that shaped.
Without boring you all too much with detail. The idea is to let the user decide whether they want the decking fitted in such a way that its running in the same direction as the caravan, or against. Once the user has decided I will then attempt to calculate from the drawing (as it will be to scale) how many full lengths of decking will it take to build this veranda (among various other items).
Now my knowledge is limited on GUI, but I'm up to scratch with panels and drawing lines, rectangles, polygons etc... My original idea was to manually draw the caravan using the g.drawLine method, same with the veranda and then base my calculations on pixel counting to calculate all the various components.
Am I out of my depth attempting this, or is this something relatively easy to program?? Is there a more efficient way of doing this that I should look up before attempting this?
What you want to do is achievable, but its not the simplest of tasks. But don't let that slow you down.
You'll want to get started by understanding how to draw in Swing. Take a look at
Graphics 2D
Custom Painting
You'll also want to be familiar with Swing in general
Creating a GUI with Swing
The basic concept with scaling, is assigning a weight to a pixel. The more distance that a pixel is responsible for, the small your image will become
Related
I have been drawing 3D graphics using the graphics.fillPolygon() method in Java. It has worked well for me so far. I can rotate the graphics by dragging my mouse across the screen, and I can zoom in and out of my graphics.
My one issue though, is finding a way to draw the polygons in the correct order so that the background polygons are not drawn on top of the foreground polygons. I know that the answer to my problem is common knowledge to the 3D graphics programmer; Some people have told me to use OpenGL, but that is too much for me to learn right now; I just want to create basic 3D graphics. I am looking for a mathematical procedure to organize my polygons in the order that they should be drawn, (from back to front).
I have thought about just taking the average distance to all points of each polygon, but that is an unreliable method. I have been using trigonometry for all of my methods, but I am starting to learn some linear algebra concepts; The use of vectors may be helpful in finding which polygons lie in front.
#Raisintoe, In computer science, binary space partitioning (BSP) is a method for recursively subdividing a space into convex sets by hyperplanes. This subdivision gives rise to a representation of objects within the space by means of a tree data structure known as a BSP tree.
Binary space partitioning was developed in the context of 3D computer graphics,1 where the structure of a BSP tree allows spatial information about the objects in a scene that is useful in rendering, such as their ordering from front-to-back with respect to a viewer at a given location, to be accessed rapidly. Other applications include performing geometrical operations with shapes (constructive solid geometry) in CAD,[3] collision detection in robotics and 3-D video games, ray tracing and other computer applications that involve handling of complex spatial scenes.
See the Wikipedia article here
This approach has been used by video games mega tubes such as Quake. You can find more about it in this excellent article by Michael Abrash where he explains how they used BSP tree in Quake to determine Quake's visible surfaces.
I Hope this helps
Yes I do agree, OpenGL is really complex, and especially modern openGL that forces you to use shaders always can get more in your way of getting things done, than actually helping you. But openGl solves this problem for you. It draws each pixel of the polygon with it's depth value. When you draw the second polygon, the pixel is only updated when it's depth value is closer to the camera than the old one. You can do the same, and you will have a pixel perfect result.
side note: Modern games engines even prefer rendering from the front to the back, because then the expensive pixel calculation in the fragment shader can be skipped for pixels that would be overdrawn anyway.
side note 2: actually you have to enable the depth test and explicitly tell, that you want the closest pixels.
I'm trying to make a project in OpenGL using JOGL.
If you see my image http://imgur.com/DDHoXEz, I have 4 viewports with different projections but all Teapots are out of "scale", and I want to make something like a bounding box, a square with side 1, that contains all objects on the viewports, to make a scale out of the square.
Any tips?
Unless you're going to use the base teapot model for programs (which you shouldn't), I don't think this is something to spend your time on. When you get into actually using your own models, you will have direct control over the scale.
I would recommend at this point learning about different drawing methods in OpenGL (e.g., GL_TRIANGLE_FAN, GL_LINE_LOOP). Then move on to learning about vertex arrays and maybe write an OBJ importer. I can point you in the right direction if you'd like.
Here is a good place to get started on different drawing techniques.
Happy coding!
i am writing a 3d modeler similar to Blender for a game i am making. Since programs like blender export very complicated file types with alot of unneeded data i wanted to write a simple editor for my game. what i cannot figure out is how to map a point from a 2d projection on the window to where i have clicked in the 3d world with the world being rotated.
If anyone knows any good tutorials on how to do this or the method any help would be appreciated. I know i could use ray tracing but that would be to complicated i think.
The two main methods of mouse picking are:
Intersection Testing
Color Picking
Intersection tests are the more popular of the two, and at the simplest level involves 'shooting' out a ray and checking if it has intersected any points. The ray can also be replaced by a polytope if one wants to achieve more sensitive picking (useful for choosing points on vertices).
Color picking involves disabling AA, blending, shadows, etc. and re-drawing the scene using solid colors for the objects. glReadPixels is then used to find the color at the point of the mouse and this color is used to determine if it clicked on an applicable object.
Ray Picking:
Mouse Ray Picking Explained
Picking, Alpha Blending, Alpha Testing, Sorting
Color Picking:
OpenGL Selection Using Unique Color IDs
Picking Tutorial
The term you are looking for is mouse picking.
The method you need is gluUnProject. You'll need window x,y and the depth.
I think, in your case, it might be a lot easier to write a simple exporter for Blender.
I'm trying to develop side scrolling game for android involving many many textures so I was thinking if I could create a separate layer, all a single unique color (very similar to a green screen effect) make a collidable and make it invisible to the player.
(foreground layer) visual Image
(2nd layer)collidable copy of foreground layer with main character
(3rd layer)Background image
I not sure if this is possible or how to implement it efficiently, the idea just came to me randomly one day.
Future regards, Thanks
I assume your game is entirely 2D, using either bit-blits or quads (two 3D triangles always screen-aligned) as sprites. Over the years there have been lots of schemes for doing collision detection using the actual image data, whether from the background or the sprite definition itself. If you have direct access to video RAM, reading one pixel position can quickly tell if you've collided or not, giving pixel-wise accuracy not possible with something like bounding boxes. However, there are issues greatly complicating this: figuring out what you've collided with, or if your speed lands you many pixels into a graphical object, or if it is thin and you pass through it, or how to determine an angle of deflection, etc.
Using 3D graphics hardware and quads, you could potentially change render states, rendering in monochrome to an off-screen texture, yielding the 2nd collidable layer you described. Yet that texture is then resident in graphics memory, which isn't freely/easily accessible like your system memory is. And getting that data back/forth over the bus is slow. It's also costly, requiring an entire additional render pass (worst case, halving your frame rate) plus you have all that extra graphics RAM used up... all just to do something like collision-detect. Much better schemes exist, especially using data structures.
It's better to use bounding boxes, or even a hierarchy of sub-bounding boxes. After that, you can determine if you've landed on the other side of, say, a sloped line, requiring only division/addition operations. Your game already manages all the sprites you're moving, so integrate some data structures to help your collision detection. For instance, I just suggested in another thread the use of linked lists to limit the objects you must collision-detect against one another.
Ideas like yours might not always work, but your continual creative thinking will lead to ones that do. Sometimes you just have to try coding them to find out!
In a small java swing 2D game, what is the best solution for creating the board view?
Use a component for the board and custom paint it and each square of the checker at once?
Use a component for the board and create another component modelizing the square with its own paint component doing the job for the square only. Use a layout to place each Square instance in the board?
I know this is subjective and I don't want a fight about it. I just need some clues to figure myself which way I should go. I've begun a side project and I've using 1), with the feeling that there is something wrong.
Just go with one drawing panel/container for everything.
Consider a tile based game. Using your second solution each tile would be an object, memory would skyrocket and the game would slow to a crawl.
Using the first option you are flexiable. You draw what you want, you have the panel coordinates so everything is relative to this. Using the tile based example you'd know the height and width of the panel, draw your square and increment in the X and Y coordinates as appropriate.
GUI frameworks such as Swing or .NET's Winforms are expensive as they have a whole lot of other stuff that a game won't need. So to answer your question, go with option one, rather than say using a panel for every checker on your board.
One nice solution to using the second method, in combination with the first method is the Flyweight Design Pattern. You still get to use OO objects, but you'll have a fraction of the amount you normally would. Check it out.
Like Finglas, I lean toward your first approach. This tile-based game is a concrete example. In contrast, this component-based game uses a GridLayout of JToggleButton. The former is somewhat more complex but plays well even on large screens; the latter is simpler yet sufficient for reasonable games. You may have to experiment with your game's geometry and logic to decide which to prefer.