How to get a special int?

Newbie & Debugging Questions
#1

Hi there JGO,

I was working yesterday and today on a small flaggscript. De borders of the flagg need to be darker then the inside flag. I have a special Colour-script to add colours. 0=dark colour, 5=lightest colour. So I say the inside of my flagg is yellow, 550 (RGB). but I want the outside a bit darker then I need to get from every number, 5 5 0, if it’s higher then 0. so 5 is higher then 0 and return it as 1, then you’ll get: 1 1 0. and finally to make the darker outside colour = 550-110 = 440. The part I have no idea how to do is the middle part(getting 110 from 550). I also don’t know what it is called, so I couldn’t search on google information or help.

Already thanks!
-RoseSlayer

#2

no idea what you are talking about :smiley:

#3

Yeah, that is the problem. I don’t know how to explain this but I can give some examples:

I have 550 and want to output 110,
I have 044 and want to output 011,
I have 303 and want to output 101,
I have 555 and want to output 111,
I have 003 and want to output 001,
I have 514 and want to output 111,

Hope this will help.
-RoseSlayer

#4 

int specialInt = 444;
String targetString = "";
String specialString = Integer.toString(specialInt);
for (int i = 0; i < specialString.length(); i++) {
	int workInt = Integer.parseInt(String.valueOf(specialString.charAt(i)));
	if (workInt > 0) {
		targetString += "1";
	} else {
		targetString += "0";
	}
}
int finalInt = Integer.parseInt(targetString);

This outputs me: 111

#5

You can use this solution I wrote and avoid the strings. I am sure that has a performance increase but by how much I’m not sure. I am pretty sure it works for all cases, but I did a couple and it seems to be working properly.


	public static int foo(int in)
	{
		int out = 0;
		
		for(int i = 1; i <= in; i *= 10)
			out += in % (i * 10 ) >= i ? i : 0;
		
		return out;
	}

EDIT
I just fixed a bug I found looking over the code. It should be <= in.

#6

Thanks for all the help, it worked.
Sorry I was a bit confusing but I even didn’t know how to explain it :stuck_out_tongue:

-RoseSlayer

#7

Here’s anothery:


   public int whateverItsCalled(int flag) {
         
        int x = 0;
        
        if(flag/100 > 0) {
            x +=100;
        }
        if((flag - flag/100 * 100)/10 > 0) {
            x += 10;
        }
        
        if(flag - flag/10 * 10 > 0) {
            x += 1;
        }

        return x;
    
    }

It relies on integer arithmetic. It also assumes that flag is <1000 (you may or may not want to handle the case that it is >1000?). Although… I feel like a bit of a spanner now. I like Jeremy’s solution; small & compact, go with that.

#8

No problem, just note that I did change the code since you last read it. It should be <= in, not < in

#9

There you go, 3 different ways, however my way was pretty inefficient. :stuck_out_tongue:

#10

I don’t know why you scale your colors in the scala [0, 5] and I also don’t know why you put them together like this into a single number.

Why not use some standard why to handle color, like one byte for red green and blue(0-255). Also there is already some classes in the standard java runtime which help you with color.


Color flag = Color.yellow;

Color border = flag.darker();

//and to get your color scaled to your [0,5] interval
public int scale(Color c)
{
   int r = c.getRed() / 51;// -> 255 / 5 = 51
   int g = c.getGreen() / 51;
   int b = c.getBlue() / 51;

   return r*100+g*10+b;
}
#11

Jeremy’s code might look better. But it uses %. which is far worse then dividing on really low level :slight_smile: Not that you will notice it. But sometimes short code isnt always the best

#12

How so? Mod is a by product of division(intel cpu integer data). So in essence % is as fast as a /.

ie:
dx:ax has the dividend
bx has the divisor
after a div…
dx has the modulos
ax has the quotient

Not sure onother archs(arm7 and 9 ds) don’t have intrinsic division.

#13

The two division instructions can be very slow for high numbers, less so for for low numbers. Division by constants is sometimes better because there are alternative ways to do division. But why bother with division at all?

public int darker(int input)
{
  final int red = 0x7 & input; // 000 000 111
  final int green = 0x38 & input; // 000 111 000
  final int blue = 0x1C0 & input; // 111 000 000
  return (red != 0 ? red - 0x1 : 0) + (green != 0 ? green - 0x8 : 0) + (blue != 0 ? blue - 0x40);
}

public int pack(int r, int g, int b)
{
  return r << 6 + g << 3 + b;
}

// unpack all 3
int input = ...;
int r = input >>> 6;
int g = (input >>> 3) & 0x7;
int b = input & 0x7;

Edit: Fixed typo and added pack/unpack code.

#14

Division can be optimized to bit shifting in some occasions as well. Which only takes like 1 clock cycle

#15

Honestly I wanted to make my game a challenge for me, where I can only use a few colours. And the colours I use are then also the bright ones. My game looks really “shiny” with this methode :smiley:

-RoseSlayer

#16

Sorry I didn’t consider the code at such an absurdly irrelevant microscopic level. Your argument is based severely on two things:

A ) Optimizations for particular architectures
B ) The underlying implementation on a OPCODE level

Which means unless your profiler makes a point about it, it means nothing in Java which has no concept of either.

I’m sure this will work fine for anyone, and if it doesn’t they shouldn’t consider hacking into bit-shifting operators unless their profiler tells them they have to.

Finally, this won’t be used for large numbers as was illustrated by the OP.

My solution was general for all integers, not specifically for an RGB colour - however I am sure if you remove that abstraction you will get some better optimizations.

#17

Yea i know. As i said. You wont notice, i was just saying that short code is not always better.