Java-Gaming.org    
Featured games (91)
games approved by the League of Dukes
Games in Showcase (580)
games submitted by our members
Games in WIP (500)
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: Unit testing rendering? on: 2007-02-10 13:37:21
you can try something like this

http://oddlabs.com/blog/?p=20

It's not exactly unit test, but it will save you time and it's very easy to implement

Thanks! It wasn't really what I was looking for but it gave me some (hopefully good) ideas. If there was just some way to log Graphics2D. DebugGraphics has a functionality like this, but only for Graphics and I need the Graphics2D transformation stuff. Maybe I can implement a wrapper myself doing something like this on all Graphics2D methods:

1  
2  
3  
4  
public void drawString(String str, int x, int y) {
   someList.add("public void drawString("\" + str + "\", "+x+", "+y+") ");  
   realGraphics2D.drawString(str, x,  y);
}


Of course, doing this manually for all functions would be insane (in a bad way). Maybe it could be made with automated code generation. I'll Google it and see if I can figure something out. Thanks again  Cheesy
2  Game Development / Newbie & Debugging Questions / Unit testing rendering? on: 2007-02-08 14:40:11
I'm working on a small 2d-game engine and I've run in to some trouble. So far I've been very strict on coding test first programming and using JUnit to test everything.  But now I've come to the point where I'm rendering simple graphics, but I have no idea how to test this.  Huh

I'm guessing I should use some how BufferdImage.createGraphics(); to create a Graphics2D, render and then check the image for result. But beyond that I have no idea how to do things. Is there any one here that has had any experience with unit testing rendering that can give me a pointer or two in the right direction?  Undecided
3  Game Development / Newbie & Debugging Questions / Re: Im new on Java, could someone please help me with my JAR heap size.. on: 2007-01-30 10:32:50
heh, im gonna make an CloseCombat 1,2,3,4,5 clone with multiple players ( no AI ) on each side and my maps will be something like 6000x6000x24 pixels..
im just training my Java skills for a future events..

I might be miss understanding you now since I've never played any of the Close Combat games but if your doing a 6000x6000 pixel then your map would take about 103 MB of memory just for the map. Might I humbly suggest you use a tile map? This is the way most strategy (Warcraft, Command and Conquer, Civilisations, Fire Emblem..) games do it.

If you have a tile size of 32 pixels you need a map of about 180*180 tiles (=6400*6400 pixels) and every tile takes 4 bytes (an int) then the map would cost you about 150 KB of RAM. And if you use need about 256 tiles (should get you far enough) this takes about 750 KB (32*32*256*3 bytes/pixel). Giving you a total map cost of under 1 MB of RAM!

But like I said, I've never played Close Combat so I'm only speculating here.
4  Game Development / Newbie & Debugging Questions / Re: Classic game loop Vs. Separate threads for update and render on: 2007-01-23 11:41:51
JustAListOfStuffToUpdateAndDraw doesn't sound like the best of class-names, but if you have a better suggestion then SceneGraph then I'll be happy to use it (i keep spelling it like "ScereenGraph" any way).  Grin

Most swing-components are rendered by the event-dispatch-thread and this means they are only rendered when something "happens". For a game this is not very practical (but now I'm probably telling you things you already know). The point of having separate threads would be to liberate the engine user from having to call update on them. He/She would just have to create the  ListOfStuffToUpdateAndDraw and add a ListOfStuffToUpdateAndDrawCanvas, attach the ListOfStuffToUpdateAndDrawCanvas to the ListOfStuffToUpdateAndDraw and not have to write his/her own game loop (the rendering engine will take care of that). A split-screen would just be two ListOfStuffToUpdateAndDrawCanvas in a JPanel with a GrindLayout. In other words the ListOfStuffToUpdateAndDrawCanvas would act like any other UI-component requiring (almost) no extra considerations.

But now that I think of it I could have the ListOfStuffToUpdateAndDrawCanvas keep a list of attached ListOfStuffToUpdateAndDrawCanvases to. This way I could have booth the single thread and my Canvases would act like any other UI-component. Cheesy
5  Game Development / Newbie & Debugging Questions / Classic game loop Vs. Separate threads for update and render on: 2007-01-21 15:11:45
For the last couple of days I've been doing some  pen and paper sketching on a small Java game. Right now I'm
trying to make up my mind about if I should use just one loop with both rendering and updating or splitting them up in separate loops. The idea is to have a SceneGraph class that holds all game objects (GraphObjects) and a SceneGraphCanvas that renders the content of the SceneGraph to the screne.

I'm leaning towards having separate threads, but I've heard some rumours that this could lead to very choppy frame rates. But if I could,  some how, get around this I think it I would have some really useful classes and thing like a split-screen would be a matter of minutes to implement. I know threading can lead to code complexity problems, but since both threads will more or less be minding there own business I don't think this will be much of a problem in practice.

SceneGraph.run() [in pseudo code]
1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
17  
18  
19  
20  
21  
22  
23  
while(running)
{
    if(!paused)
    {
       while( there still are canvases rendering this graph)
         Sleep(2)

      - calculate delta time and FPS
      - Update all graph objects

      - Collision detection on all GraphObjects
      - Collision reaction
     
           
      m_cycle_count++
     
      Sleep(5);
    }
   else
    {
       Sleep(100)
    }
}



SceneGraphCanvas.run() [in pseudo code]
1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
while(running)
{
   if(m_screen_graph.m_cycle_count > m_last_rendered_cycle)
   {
      renderScreenGraph()
      m_last_rendered_cycle = m_screen_graph.m_cycle_count
   }
   else
   {
      Sleep(10)
   }
}

(SceneGraphCanvas extends javax.awt.Canvas)

Does this sound like a reasonable way to do things?

Have any one here tried something like this? If you have I'd really like to hear if and how you got it to work (or why you didn't and why it's a really stupid idea to use the separate threads approach)
Pages: [1]
 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

xsi3rr4x (50 views)
2014-04-16 02:08:23

BurntPizza (46 views)
2014-04-15 11:46:01

UprightPath (62 views)
2014-04-15 01:39:50

UprightPath (44 views)
2014-04-15 01:35:47

Porlus (60 views)
2014-04-14 23:48:38

tom_mai78101 (84 views)
2014-04-10 12:04:31

BurntPizza (142 views)
2014-04-09 07:06:04

tom_mai78101 (242 views)
2014-04-05 21:34:39

trollwarrior1 (201 views)
2014-04-04 20:06:45

CJLetsGame (208 views)
2014-04-01 10:16:10
List of Learning Resources
by SHC
2014-04-18 11:17:39

List of Learning Resources
by Longarmx
2014-04-08 11:14:44

Good Examples
by matheus23
2014-04-05 21:51:37

Good Examples
by Grunnt
2014-04-03 23:48:46

Good Examples
by Grunnt
2014-04-03 23:48:37

Good Examples
by matheus23
2014-04-02 02:40:51

Good Examples
by matheus23
2014-04-02 02:40:34

Anonymous/Local/Inner class gotchas
by Roquen
2014-03-11 23:22:30
java-gaming.org 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‑gaming.org
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!