Might automated SCAM posting apps be getting smarter? Do they have some site that adertises something like this?

SCAMMeister 3.1 (now with automatic member registration in forums!!)

Supports:
*email
*usenet
*YaBB
*...

Next release will include Massive Multiplayer Online Games!!

I hope not!

Seb

Perhaps you could just skip rendering some frames in a single threaded update/render loop when it would cause too much of a delay.

This of course wouldn't look too nice as skipping frames might be noticeable by the user sometimes, but it's an idea.

Seb

Apparently, despite the marketing fud, it doesn't seem to be actual 3D in Flash. It's rather a separate applet being controlled by a flash file through the browser's Java script.

But still this is not necessary as the applet seems to be completely stand-alone.

Seb

Use the link Chris provided.

A note to the site admins: When I went back to edit my post I saw that the link is correctly written in the url tag, I left it lke that. Some springs might be loose when generating the page I guess.

Seb

Allright, I just posted at JL a summary of most things said so far including this thread.

However I'm not cross-posting as my intention is to have you reply over there so that the broader community gets to read and participate, not just us guys over at the gaming forums. Thanks,

Seb

Hi Cas,

In Rick's own words: "we have been having a mysterious problem with connections bombing [...] should be fine now".  

Give it another try and let me know how it goes. Thanks,

Seb

Hi,

I started a thread over at JavaLobby about the different suggestions on how to implement structs.

Why JavaLobby? Well it's my job, I'm an editor there , but most importantly because I think it a great location to get input from the whole community on this particular matter that goes beyond the development of games so that all ideas are put on the table and other people are exposed to the possibility.

Perhaps get a serious and complete proposal going.

Seb

Darn, someone should move the structs thread over at Off Topic into Performance Tuning.

Anyway, I think we need someone to write an article detailing all the different reasons different people propose structs, and compare the proposed solutions.

The article might conclude structs won't be the best solution to some of these performance problems, and escape analysis will do there. The article will explain to those affected why escape analysis is better in these cases and why structs will be better in other cases.

Then it will go on to propose a struct design that solves all problems not solved by escape analysis and perhaps by some other means.

This will hopefully unite developers into supporting this common design (well, I did say hopefully) and form the basis of a serious community backed design to present to Sun.

Anyone up for it? Write the article I mean.

Seb

Here's the changelog for build 12:

http://forums.java.net/jive/thread.jspa?threadID=58&tstart=105

Seb

Hi Cas, you might be interested in visiting the Mustang Forums, they are also pushing for structs there maskerading under extprim or some such.

Seb

I've got 4 gmail accounts. Anybody want?

Seb

The Web Site: http://seb.citycolor.net

The resume: http://seb.citycolor.net/cv/currEN.html

I'm a IT Consultant (Programming included) and Graphic Artist. Check out the Web Site for an idea of what I do.

I'm mostly interested in offshore work. I'm good and inexpensive!!  

However, I'll consider all proposals.

Seb

Never mind, I just read your diary  

Seb

By the way, what is the actual value buttonFlags has in each VM?

In other words? is this an assertion bug? or something really funny in the the way the server VM handles bit ORing.

Seb

Here's another emulation framework in Java. It's not as functional as Cottage.

http://jfrace.sourceforge.net/index.html

Seb

Well, a TreeMap wasn't in my mind at all.

Lemme' try to say it clearly in one posting.

CPU opcode formats usually have some sort of semantic logic to them. Take some z80 instructions for example (What I'm gonna say is oversimplified but it makes the point) :

----------- 76 543 210  76543210
LD r,r'     01 ddd sss
LD r, (HL)  01 ddd 110
LD (HL), r  01 110 sss
LD r,n           00 ddd 110  nnnnnnnn
LD (HL), n  00 110 110  nnnnnnnn

Well, having the most significant bit (bit 7) equal to 0 means we're doing a load/store.

• The next bit (bit 6) equal to 1 means there are no immediate operands and we proceed to figure out destination and source from the next two pairs of 3 bits. If one of these is 6 then it means indirect addressing for source or destination, using the address at HL, otherwise we're referring to one of 7 registers.
  
• If instead, bit 6 were 0, then we have an operand on the next byte. If the source is 6, were once more using indirect addressing.
  

The thing is, this structure lends itself to hierarchical decode (hence my commenting this being similar to a tree search, although it wasn't the most appropriate way to describe it I admit   )

This, of course, is not as efficient as the switch compiled to a table lookup, I just mentioned it because it seemed elegant and because I wasn't sure at the time if javac did lookup-table optimization on switch/case so I figured it could provide a performance boost. But I wouldn't implement this with a TreeMap, I would hardcode the decoding process.

Seb

Xbrain,
Although the VM could possibly identify which opcodes are used more frequently, I'm afraid there's not much it can do to optimize those particular code paths.

It can't inline anything a that point based on frequency of access, it has to handle all possible situations. So there's not much optimization possible other than a jump table a this point.

Even the method I proposed in the previous post, the hierarchical decode, is probably slower, I only like it because it seems like an elegant solution, but that would have to be seen in an actual implementation.

Seb

Well, I don't know if it would make things faster, nor do I propose it as a final solution. I'm just discussing the different methods since I find it worth while. With the switch statement working through a lookup, I think it's hard to find something that works faster.

I agree it's not optimal to emulate close to the hardware in many cases. However in the particular case of part of the decode circuitry it appears to me it could be good. But I'm just imagining a particular type of decode circuitry. One that would look like an opcode search tree.

Using a search tree, one could be garanteed that it would find the code for an opcode within, say, 8 or so tree lookups max, for 8 bit opcodes. It also seems flexible enough to account for different bit sizes in opcodes naturally.

This tree wouldn't have to exist as a complete tree either. It's only the search that's structured hierarchically, starting by verifying the most significant bits first, not necessarily one bit at a time.

Different points in this hierarchical decode I suggested one could implement either with switch statements or with jump tables. But, as you said, it can all be done with switch if being careful. You're right, it's not that hard to maintain that code, just gotta' know how to get the compiler to compile right.

Seb

Well, that was my question, if anybody had tried the method.

I'm also not sure if javac uses internal jump tables at any point for switch statements.

As for doing it by hand. I figured that although bound's cheking is NOT turned off here, (that usually works only for array access inside some 'for' & 'while' loops where the array index is also the loop counter) it could still be faster than even short switch statements.

Also, if javac does implement jump tables when it can, these are rare occasions, one would probably have to be careful to sort the cases, make sure none fall through, make sure there are no gaps, etc..

Seems complicated and any careless modifications could alter performance wildly.

An intermediate solution is probably to research how the original processor did the decode stage and code something analogous to that circuitry.

I'm calling this intermediate because I figure in most cases CPUs start decoding by the most significant bit or bits, perhaps ending up with something similar to a search tree, and some parts in this tree could implement jump tables and some other switch statements or directly execute some opcode.

Seb

True, but you have no control over it.

Seb

Just to clarify what I said above a little more.

The idea is eliminate the switch statements in the main loop, which I think are much slower for interpreting, and are way too popular in main message loops for my taste.

Seb

I'm just curious, remember jump tables? Used to be useful when doing assembly or even C.

In the case of an emulator, if the CPU being emulated had one byte opcodes, then it's possible to build a jump table for them, having a very simple main loop.

Maybe this is the way things usually work, say, in MAME. I've never looked at emulation code.

I wonder how well a jump table would work in Java? Taking into account the way the VM optimizes code.

Of course, you would have to have a class table in this case of classes implementing something like CpuOpcode



Of course, it's a tad more complicated than this since there usually are some two byte opcodes and stuff. But the basic idea is that.

It would probably be hard for the VM to optimize some of this I'm sure when compiling to native, perhaps it isn't even a good idea for native emulators. Any comments?

Seb

It worked fine here.

JRE 1.4.1_01 / WinXP SP1 / Athlon 1400+ / PCChips 810

smooth animation too.

By the way, very cool demo.

Seb

Yup, I got the same screen.

The server is off. please come back between so and so Spain time-zone.

Seb

I am about to try Nabetse's mutiplayer game. I'm doing this on a freshly installed machine. The thing is its so fresh I didn't install the JRE yet, which I normally install manually.

So when I click on the link to load the applet. It automatically started downloading the JRE from Sun. We all know it does this. But as developers, we usually have everything preinstalled. It's nice to se thinks work as they would for the average user from time to time.

And my impression is that at 256kbps, it's completely confortable, taking a well announced 5 minutes. That is, there are no loooong I-dont-know-how-much-this-takes waits anymore.

So it's not the flash plugin yet, but it's completely acceptable now. at least at 256kbps.

I'm in Argentina, 256 isn't the norm here however, how'bout down there (yes, south is up   ) what's the typical users bandwidht?

Seb

Actually, I might be partially wroung here. My motherboard might still use AGP circuitry to negotiate the reading/writing on the video part of RAM, which might slow things down a tad. It might even send the data through the bus at 1x, 2x or4x speed.

In any case, this could still apply to your linux box, as it could have a completely different and straight forward architecture. I miss the old Atari ST days, that machine had all of system RAM available to video, working at twice the speed (16MHz!!!) of the CPU, the memory was accesed by both on alternate cycles. So the CPU never had to wait to use RAM. Anybody have any 4GHz DIMMs?

Seb

PD: Me, I didn't mean to piss me off by correcting myself, so don't flame me.

There are other reasons as to why there could be such a performance difference between systems, not talking about sleep() here.

• There are some known problems when using jre 1.4.1 with some geForce 2 MX cards. Although I don't think it applies to you since 150fps is not bad anyways. They are working on this. (see the thread on side scrolling, there's a mention there)
  
• video memory is normally accessed through AGP. This might slow down graphics in some circumstances. I have a cheap motherboard that uses system RAM for video and, although sharing RAM between CPU and video is generally not optimal, there is no transfer of data through the AGP. This makes my cheap motherboard very fast when writing/reading on 'video' RAM. The same might apply to your linux box.
  

Seb

This might not need the VM spec be modified.

The native JIT compiler could possibly optimize the casting verification away based on extended properties found in the class file left there by the java compiler.

I still find generics in Java, although somewhat useful, to be a rather bulky hack. I mean, it's not a very elegant solution, adding hidden methods (not in the source code) behind your back.  This is of course unavoidable when you aim to maintain backwards compatibility.

Seb

Coooool!

Now they need to spice up that simulation into a nice little game  .

Seb

Old thread, new info...

Since I posted the last message I upgraded my computer. My new setup is Windows XP on a Duron 1200. I'm still using both the geForce and the Matrox. Both are using microsoft drivers this time, last time I was using the original nVidia and matrox drivers.

What's curious is that I'm still having bad performance if I don't disable Direct3D on Java2D

So it appears the problem is not a driver issue. It seems to be either with the card itself, or Java2D's use of Direct3D.

Seb.