I heard you like Java

[ToshiroHayate]

@Tygar:

> Nice FPS.
> Too bad it wasn't real. xD
>
> Actually wait, your computer would explode drawing that fast.

What are you talking about? You can set your FPS gap to any number. If he's connected to himself, then of course there's infinite FPS. Just because you have an x number of FPS doesn't mean it's processing at that speed.

[emblem]

@Jungletoe:

> It's not real? Why?

Let's take my computer for example, it's 2.5 Ghz.  Mines a dual core so that's 5.0 Ghz total or 5,000,000,000 Hertz.
Processors nowadays are 64bit meaning, 64 bits of data (IE 8 Bytes) is passed to the CPU per clock.
So in theory, my CPU can process 40,000,000,000 byte instructions per second.

On average a single ASM instruction is 4 bytes. So 10,000,000,00 bytes per frame assuming the instruction to draw the frame is a single instruction (Usually it's a good 100,000 instructions).

In computer terms, unsigned infinity is 4,294,967,296.
So that leaves us with it going at about twice the speed of unsigned infinity, while using only a single instruction and using 100% CPU on my Dual Core 2.5Ghz CPU.

Now, take into account various things such as other open programs, and the fact that drawing a single frame is ALOT more complex than a single instruction, it's clearly impossible, at least on an average computer.

Don't ask how I know this. xD

@Toshiro:

> What are you talking about? You can set your FPS gap to any number. If he's connected to himself, then of course there's infinite FPS. Just because you have an x number of FPS doesn't mean it's processing at that speed.

FPS is not ping.

See above, also.

[Homicidal Monkey]

@Tygar:

> Let's take my computer for example, it's 2.5 Ghz.  Mines a dual core so that's 5.0 Ghz total or 5,000,000,000 Hertz.

first, it doesn't work like that. Dual core means you can run two processes at 2.5ghz (and depending on your CPU) average is 2 threads per core.

> Processors nowadays are 64bit meaning, 64 bits of data (IE 8 Bytes) is passed to the CPU per clock.
> So in theory, my CPU can process 40,000,000,000 byte instructions per second.

also doesn't work like that. You can only pass 1 instruction per cycle. 64bit means that instruction can be as large as 64bits. So 1 byte takes up as much cpu as 1 64bit integer.

also the FPS count IS actually throwing Infinity. u mad?

[emblem]

@Fabio:

> first, it doesn't work like that. Dual core means you can run two processes at 2.5ghz (and depending on your CPU) average is 2 threads per core.

Okay, I was wrong. The little bit of research I did failed. xD

@Fabio:

> also doesn't work like that. You can only pass 1 instruction per cycle. 64bit means that instruction can be as large as 64bits. So 1 byte takes up as much cpu as 1 64bit integer.

Didn't know that, thanks for sharing.

@Fabio:

> also the FPS count IS actually throwing Infinity. u mad?

Literally the string literal "Infinity"?
o.o

[Homicidal Monkey]

@Tygar:

> Literally the string literal "Infinity"?
> o.o

yup. it throws infinity. The graphics only draws anything that changed which for the most part, is nothing.

[emblem]

@Fabio:

> yup. it throws infinity. The graphics only draws anything that changed which for the most part, is nothing.

Didn't think of that. :p

So technically it's drawing a frame every 0ms?
That would explain. xD

[Homicidal Monkey]

@Tygar:

> Didn't think of that. :p
>
> So technically it's drawing a frame every 0ms?
> That would explain. xD

thats actually extremely close.
it actually locks it at ~60fps.
the fps calculated is the ideal fps (fps if it didn't lock). it does this by timing how long it takes to draw 1 frame (mspf) then taking the inverse (fpms * 1000 = fps). If it takes less than 1ms to render 1 frame, then fps = 1000/0 aka infinity.

[Godlord]

@Tygar:

> Let's take my computer for example, it's 2.5 Ghz.  Mines a dual core so that's 5.0 Ghz total or 5,000,000,000 Hertz.
> Processors nowadays are 64bit meaning, 64 bits of data (IE 8 Bytes) is passed to the CPU per clock.
> So in theory, my CPU can process 40,000,000,000 byte instructions per second.

If your core has a clock rate of 2.5GHz, it simply means it can handle 2.5 * 10243 cycles per second. What this means, ignoring µops however, is that it can handle a sequence of instructions whereof the sum is that amount of cycles every second. Cycles are however not the same as instructions, as instructions might take one cycle, two cycles, three cycles or even half a cycle to process (the latter is an example of the Intel Pentium I which had two pipelines to handle two instructions in sequence at the same time when possible).

Your claim of processors being 64-bit nowadays is totally false and so is your definition. That size you specified only refers to the data bus of the processor. e.g. the 8088 is an 8-bit Intel processor, the 8086 is a 16-bit Intel processor, the 80486 is a 32-bit Intel processor and the Intel Xeon is usually a 64-bit Intel processor. Now as why your claim is false: the mobile market is infected with ARM processors, which are only available in 32-bit (with ARM Thumb which is 16-bit or ARM's 8-bit extension). In fact, ARM _never_ designed a 64-bit processor, and probably never will for the next few years.

Then you also start using the total amount of cycles for a SMP/NUMA-processor, which isn't exactly right either. The reason for this is that software isn't designed to run at multiple processors at the same time. In the end your software will only use one core, unless you are running an operating system to handle tasks differently and run an application written to use that "technology."

@Tygar:

> On average a single ASM instruction is 4 bytes. So 10,000,000,00 bytes per frame assuming the instruction to draw the frame is a single instruction (Usually it's a good 100,000 instructions).

There is no average size, unless you are developing for a RISC architecture. e.g. ARM instructions are always four bytes long, whilst x86-64 instructions can be one byte at minimum, but fifteen bytes at maximum. I.e. your calculation is flawed.

@Tygar:

> In computer terms, unsigned infinity is 4,294,967,296.
> So that leaves us with it going at about twice the speed of unsigned infinity, while using only a single instruction and using 100% CPU on my Dual Core 2.5Ghz CPU.

In computer terms infinity is non-existent unless you set up a standard like IEEE 754.

I respect you, but please don't mess in a field you are not experienced enough at.

@Fabio:

> thats actually extremely close.
> it actually locks it at ~60fps.
> the fps calculated is the ideal fps (fps if it didn't lock). it does this by timing how long it takes to draw 1 frame (mspf) then taking the inverse (fpms * 1000 = fps). If it takes less than 1ms to render 1 frame, then fps = 1000/0 aka infinity.

Considering how much time it takes to render a frame is sometimes extremely dynamic, your formula wouldn't work properly. Plus, your formula should be like: ceil(fpms) * 1000 = FPS (since a duration near zero, doesn't mean it is actually zero and as it seems you don't want to use the FPU, you should use proper integers instead). But even better would be to just increment a variable every frame and reset it every second.

Regards,
  Stephan.

[Robin]

**ITT:** _Real_ computer nerds.

[VitinhooxD]

I didnt understand a word of what Stephan said.

[Homicidal Monkey]

@[Cake:

> Woods â„¢ link=topic=67666.msg731651#msg731651 date=1294686485]
> I didnt understand a word of what Stephan said.

thats normal.

@Robin:

> **ITT:** _Real_ computer nerds.

jelly?

@Stephan: The fps is already limited to 60, if I incremented an integer every frame, I'd get ~60fps and therefore telling me something I already knew. The purpose of taking the inverse of mspf was to return the number of frames that could be rendered in a second while still capping fps. Personally, the "Infinity" fps was a joke. I could use higher precision timer, but where's the fun in that?

[Robin]

inb4 I release the next Origins with 'infinity' hardcoded rather than counting the FPS.

[VitinhooxD]

@Robin:

> inb4 I release the next Origins with 'infinity' hardcoded rather than counting the FPS.

inb4 you release a Origins update which doesnt update nothing but the "infinity" hardcoded.

[Robin]

@[Cake:

> Woods â„¢ link=topic=67666.msg731658#msg731658 date=1294689554]
> inb4 you release a Origins update which doesnt update nothing but the "infinity" hardcoded.

That'd probably be more effort than it's worth due to the fact that I've already begun optimising everything.

[Godlord]

@Fabio:

> thats normal.

Haha.

@Fabio:

> @Stephan: The fps is already limited to 60, if I incremented an integer every frame, I'd get ~60fps and therefore telling me something I already knew. The purpose of taking the inverse of mspf was to return the number of frames that could be rendered in a second while still capping fps. Personally, the "Infinity" fps was a joke. I could use higher precision timer, but where's the fun in that?

Your formula still isn't accurate however, since you are assuming all sixty or even n frames take equally long to render. Just use the normal way and disable the vsync capping (and if you implemented it manually, make sure you deal with the different frequencies; 60Hz isn't the only player in the arena).

Regards,
  Stephan.

[Homicidal Monkey]

@Stephan:

> Your formula still isn't accurate however, since you are assuming all sixty or even n frames take equally long to render. Just use the normal way and disable the vsync capping (and if you implemented it manually, make sure you deal with the different frequencies; 60Hz isn't the only player in the arena).
>
> Regards,
>   Stephan.

FPS isn't capped via vsync, the call is actually set to run every 16ms as long as it executes one refresh in under 16ms.

[demon xxx x]

I'm just amazed at what Eclipse is becoming..

[SawQuart]

It's the whole Mirage scene that's making this transformation, or at least planning it. I've heard of a few other Java engines in progress on other sites.

[Homicidal Monkey]

@Jungletoe:

> It's the whole Mirage scene that's making this transformation, or at least planning it. I've heard of a few other Java engines in progress on other sites.

lol I think we have the most developed. Just need to finish a few things server-sided

[turbocookie]

Dunno if this is irrelevant or not but. People will be able to bot alot easier then, like runescape, i have the most profesional bot for that, its java, so im sure it can be done for anyone elses game, will have to put some anti bot stuff in a game if i used this :) although you can bot anything. lol why am i still typing? aha bye

[Ruins of Hell]

You can bot Eclipse games as well. The reason there is Runescape bots is because it's popular.

[Robin]

@Turbocookie:

> Dunno if this is irrelevant or not but. People will be able to bot alot easier then, like runescape, I have the most profesional bot for that, its java, so im sure it can be done for anyone elses game, will have to put some anti bot stuff in a game if I used this :) although you can bot anything. lol why am I still typing? aha bye

You can bot on any game using any language. Having the engine in Java doesn't make it easier or harder to bot.

[SawQuart]

It's not easy to make a bot either. You'd have to have a huge motive to make one for an Eclipse game. It's not like you can brag to your friends "Oh yeah, I'm lvl 27905 on (Insert Crappy Name Here) Online!", since they'll most likely have no idea what the duck you're talking about.

inb4 some genius admin saying it's not hard to make a bot

[Robin]

@Jungletoe:

> inb4 some genius admin saying it's not hard to make a bot

You don't need to be a genius to make a packet duplicator.

[Ruins of Hell]

@Jungletoe:

> It's not easy to make a bot either. You'd have to have a huge motive to make one for an Eclipse game. It's not like you can brag to your friends "Oh yeah, I'm lvl 27905 on (Insert Crappy Name Here) Online!", since they'll most likely have no idea what the duck you're talking about.
>
> inb4 some genius admin saying it's not hard to make a bot

Making a bot is easy, considering you can emulate keypresses in pretty much every language out there. You can set it up next to a resource and make it hold CTRL, and just like that you have a bot that farms trees.