Hi !
Featured games (90)
games approved by the League of Dukes
Games in Showcase (777)
Games in Android Showcase (231)
games submitted by our members
Games in WIP (856)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
   Home   Help   Search   Login   Register   
  Show Posts
Pages: [1]
1  Game Development / Newbie & Debugging Questions / Re: How to load .obj files with textures into JOGL/LWJGL program on: 2016-06-29 04:21:15
I wrote a parser some time ago, it's pretty full featured.  It will take care of all of the parsing of the file and let you concentrate on writing the OpenGL code.  (There is also some 'old' style OpenGL example code using LWJGL but if you're new to OpenGL you're much better off learning the modern approach to OpenGL instead.)
2  Java Game APIs & Engines / Java 2D / Re: 2DGraphics PixelArray vs G2d.drawImage(...).. on: 2012-10-05 03:40:59
The answer is, it's complicated.  It depends a lot on what you want to do with the pixels and such, and what you're doing with your graphics.   I'd take a stab and guess that you can probably just use g2d.drawImage(), but the simplest thing is to start with that and see if things run to slow for your tastes.  If they do, then profile and see where the problem is, it might be somewhere other than drawing. 

But for a bit of background, basically images can be in tons of different formats, and the image classes hide a lot of that complication from you.  If the format of your image doesn't match the format of your graphics device, then every time you draw the image the code under the covers does a lot of work converting each pixel in your image to the graphic device format.  On the other hand this code is usually written pretty well and they can take advantage of lots of other stuff like caching images inside the graphics card, etc.  Conceivably (a little bit of a guess here, as I don't muck around that deep in this kind of code) a call to drawImage() might be converted into a call across to the memory card, and use hardware to blit an image from one part of the graphic card memory into another part of the graphic card memory, very very quickly.

On the OTHER hand, if you know exactly what format your image or images are in and you know exactly what format you want to write it to, you can get at the underlying data structures (i.e. DataBuffers) and just munge the numbers yourself.  Unfortunately once you ask Java to get at that data, all that magical code the sun guys wrote way back when can't rely on you not pulling the rug out from under them, i.e. they mark that image as "do not cache on the graphics card, ever", because they have no way of knowing if you wrote to that underlying big honking array of pixels.  So now while you can do a lot of manipulations on the pixels a lot quicker, you can't take advantage of whatever hardware acceleration might be going on, or whatever other goodness the sun guys wrote under the covers. 

Make sense?  The real answer is that it greatly depends on what you're doing.  Mind you there are a lot of things you can do to make things faster without mucking around with the pixels and messing up acceleration.

Among other things make sure that you create the BufferedImage that you're drawing too by calling createCompatibleImage on GraphicsConfiguration.  This will hopefully avoid a having to convert all the pixels of the image you're drawing to the screen from one format to another, each and every time you draw. 

Overall I suggest you start with that, and if things are too slow ABOVE ALL PROFILE your code because the slow part may very well not be in drawing to the screen.  If you find it is the drawing that slows things down then do more research on the web.

Finally I leave you with the three Rules Of Optimization

1) Don't do it
2) Don't do it yet
3) Profile
Pages: [1]
hadezbladez (290 views)
2018-11-16 13:46:03

hadezbladez (159 views)
2018-11-16 13:41:33

hadezbladez (291 views)
2018-11-16 13:35:35

hadezbladez (72 views)
2018-11-16 13:32:03

EgonOlsen (2151 views)
2018-06-10 19:43:48

EgonOlsen (2177 views)
2018-06-10 19:43:44

EgonOlsen (1366 views)
2018-06-10 19:43:20

DesertCoockie (1984 views)
2018-05-13 18:23:11

nelsongames (1626 views)
2018-04-24 18:15:36

nelsongames (2273 views)
2018-04-24 18:14:32
Deployment and Packaging
by mudlee
2018-08-22 18:09:50

Java Gaming Resources
by gouessej
2018-08-22 08:19:41

Deployment and Packaging
by gouessej
2018-08-22 08:04:08

Deployment and Packaging
by gouessej
2018-08-22 08:03:45

Deployment and Packaging
by philfrei
2018-08-20 02:33:38

Deployment and Packaging
by philfrei
2018-08-20 02:29:55

Deployment and Packaging
by philfrei
2018-08-19 23:56:20

Deployment and Packaging
by philfrei
2018-08-19 23:54:46 is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!