Java-Gaming.org    
Featured games (81)
games approved by the League of Dukes
Games in Showcase (498)
Games in Android Showcase (117)
games submitted by our members
Games in WIP (563)
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  Java Game APIs & Engines / Java 2D / Re: Grabbing palette index from a pixel on: 2003-04-10 22:07:20
I considered this, but the team members who are going to be working on this map will most likely not have a clue how this works.

It's easier to say "each colour represents a block type" than to say "colour #001001001 represents block 1, #002002002 represents block 2.. " etc.

I guess a palette could always be provided to make sure the correct colours are always used, but then it limits the software they use.

For the moment though, JFrames are the way forward  Grin
2  Java Game APIs & Engines / Java 2D / Re: Grabbing palette index from a pixel on: 2003-04-10 14:48:46
What I'm trying to do is use a bitmap as a very simple level-map, with each colour index representing a block type.

I know there's a lot of map systems out there, but this is for a Uni project where every bit of code should be my own, and also has to be fully tested by myself.

So, I guessed this would be a nice easy way to implement a level map, and also get a free map editor in the process (MS Paint  Grin ). It's worked for me really well on other platforms before, and it gives GIF compression on the map in the bargain.

I think I'll ditch the Applet and move to a JFrame, since the alternative idea of writing my own map format, loader and editor is just too much hassle for this   :-/
3  Java Game APIs & Engines / Java 2D / Re: Grabbing palette index from a pixel on: 2003-04-08 21:25:45
Thanks for the reply again. That's what I thought Sad

By tweaking the RGB values of the temporary palette, I did notice that the function is trying to be smart by remapping the image, thus destroying the data I want  Angry

Are there any non idiot-proof methods for doing a direct data transfer from an Image to a BufferedImage?

Is getImage() the only way to load images in an applet?

If so, is there *any* other way to access the raw data of an Image?  

Such a simple thing, and yet so awkward.

*tears hear out*
4  Java Game APIs & Engines / Java 2D / Re: Grabbing palette index from a pixel on: 2003-04-08 18:31:34
Hi,

Ok, ran into a new problem.

When using ImageIO to load into a BufferedImage directly, the above works fine.

I can't use this though, since I'm writing an applet. Have to use getImage() instead.

So, I created a BufferedImage with type TYPE_BYTE_INDEXED, and gave it a new IndexColorModel object. Then I drew the previously loaded Image onto it.

So far so good. However, using the above code to grab the palette index from a pixel just gives nonsensical values.

Here's the code:

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
            //create a new indexcolormodel
           byte[] t = new byte[16];
            IndexColorModel icm = new IndexColorModel(4,16,t,t,t);

            //draw the loaded image onto a BufferedImage
           tempImage = new BufferedImage(w,h,BufferedImage.TYPE_BYTE_INDEXED,icm);
            tempImage.createGraphics().drawImage(tempImage2,0,0,null);

            //grab a pixel
           int [] pixel = new int[1];
            tempImage.getData().getPixel(0,0,pixel);

            System.out.println(pixel[0]);



On a bitmap where the first three horizontal pixels have the values 1,2,1  this code will return 15, 15, 15.

Any ideas?
5  Java Game APIs & Engines / Java 2D / Re: Grabbing palette index from a pixel on: 2003-04-08 14:42:44
Hi,

That done it, thanks. Was previously trying to access the DataBuffer instead of the Raster, and it was giving strange results.

Although, it's getPixel(x,y,pixel) instead of getDataElement() Smiley

Thanks, again.

David
6  Java Game APIs & Engines / Java 2D / Grabbing palette index from a pixel on: 2003-04-07 14:51:34
Hi,

I have a 16 colour indexed/paletted bitmap. After loading this into an object, I want to look at the image data and grab the palette index for a specific pixel.

How can I do this?  I tried using a BufferedImage, being too stupid to realise that getRGB actually returns a colour value instead of an index. D'oh.. I'm too used to retro programming Roll Eyes Grin

Besides loading the bitmap in manually and sifting through the data, is there a lazy way to do it?

Speed isn't important.
7  Java Game APIs & Engines / Java 2D / Re: (un)Smooth movement on: 2003-02-13 13:20:38
Thanks, I reckon some of this has made a difference.

Cheers  Grin
8  Java Game APIs & Engines / Java 2D / Re: (un)Smooth movement on: 2003-02-13 07:24:45
Thanks for the replies  Smiley

GC would make some sense I suppose. I'm not doing much real code at all in the main loop though, certainly no alloc/dealloc. Just simple move->draw->wait->repeat.

Does GC always run at a set rate irrelevant of what your program is actually doing? I've not looked very deep into the mechanics of this before.

Its not a massive stutter, just noticable. Maybe I'm too used to my Amiga's lovely smooth scrolling?  Grin
9  Java Game APIs & Engines / Java 2D / (un)Smooth movement on: 2003-02-12 13:25:37
I'm having a bit of a problem with the smoothness of my graphics.. or the lack of it!

I'm using a dead simple Applet and Thread, and the graphics are drawn using active rendering. My main loop is pretty traditional:

1  
2  
3  
4  
5  
6  
7  
8  
run()
{
   gameLogic();
   render(backBuffer);
   swapBuffers();
   try{gthread.sleep(20);}
   catch (InterruptedException e){}
}


The game logic is non existent at the moment, so it basically just throws things at the screen.

The problem is that while it maintains a fairly constant speed, it'll jerk/judder/stick every second or so. It's perfectly smooth in-between these judders, which makes it seem like (to me) that something is interrupting my program periodically.

My other thought was that some frames may be taking vastly different times to draw than others, causing intermittent speedups/slowdowns. So, I tried using a Timer object to invoke the drawing of frames at a set rate, and it made absolutely no difference.

I also wrote a small method to calculate the amount of time taken to draw a frame, and subtracted that time away from a standard delay. I then made the thread sleep for this amount of time. This should make each cycle of the loop take roughly the same time.. right? But it still behaves *exactly* the same..

I've tried the program on all sorts of hardware and Windoze versions.

Any suggestions?
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.

radar3301 (13 views)
2014-09-21 23:33:17

BurntPizza (31 views)
2014-09-21 02:42:18

BurntPizza (22 views)
2014-09-21 01:30:30

moogie (20 views)
2014-09-21 00:26:15

UprightPath (29 views)
2014-09-20 20:14:06

BurntPizza (33 views)
2014-09-19 03:14:18

Dwinin (48 views)
2014-09-12 09:08:26

Norakomi (75 views)
2014-09-10 13:57:51

TehJavaDev (104 views)
2014-09-10 06:39:09

Tekkerue (51 views)
2014-09-09 02:24:56
List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06

List of Learning Resources
by SilverTiger
2014-07-31 11:54:12

HotSpot Options
by dleskov
2014-07-08 01:59:08
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!