So for the first time in a few years I tried AWT

Performance Tuning
#61

[quote]1) I don’t like the attitude towards open source. Open source does not suck - just like commercial products do not suck.
[/quote]
If you think I have a bad attitude towards os software, you’re probably misreading my posts - my chief complaint is that there is VERY good os sofware out there, but it gets buried in a sea of drivel. I find this painful (I suffer) and frustrating (I feel sorry for the authors of great apps that get much less exposure than they deserve because they are obscured by crud). I’ve already said that I see windows and linux as being as bad as each other, by which I imply also a rough equivalence in quality between open and closed source software…

Anyone who uses windows for a long time knows that lots of the OS and MS products make you want to throw the computer out the window in frustration sooner or later - it’s certainly far from a shining example of “what linux should be like” - but it does get a lot of things very right that most linux installs get very wrong. Many linux advocates forget / ignore this.

Closed source apps that suck as much as the bad os software tend more often to vanish quickly since they can’t make any money being sucky; commercial software has this “self cleaning” mechanism built-in. The closest that os software gets to this may be that SF.net is now slowly introducing automatic deletion of projects with zero activity.

(FYI: as far as possible I use and mandate software that uses good, and open, standards; I don’t care whether the source is open (it’s often too impenetrable for me to have any realistic benefit from access to it), but open source software more often follows open standards, and more faithfully - so I use much more open source software than closed).

This topic has become quite a mutual complaining session about linux problems, for which I’m partly to blame, but I think this was mainly done to illustrate the problems which many people still try to pretend are not so prevalent as they really are. And to warn java developers of the problems they (and their linux-using potential customers) face…

#62

I said nothing along those lines.

Taking JOGL, note that the JOGL that opengl.org pointed to was for a long time a different (discontinued) JOGL. This is a classic example of the problem I highlight: if I told someone “there’s this great open-source OGL for java, called JOGL” and they (sensibly) looked on opengl.org, they’d find something else entirely, and might well decide I was a misguided fool, and give up.

Anyway, in percentage terms, those 4 things are a water molecule in the ocean of open source software. I stand by my comment that “most” open source software is bad, whilst accepting that I’m being extreme and not substantiating my argument numerically - it’s merely a personal perspective from personal experience on something that’s not really quantifiable (unless you have the resource to e.g. analyise every SF.net project).

#63

I think Open-Source has a similar mechanism and maybe it’s even stronger, because all competitive products have the same price (zero). The users will pick the one that suits best and less popular software will vanish.

[topic: Openoffice has sometimes problems reading MS formats]

[quote]Yeah yeah whatever! So what? Who cares? If you’re trying to be compatible with someone else’s software, it’s not their problem, it’s yours. Historically (look at the last 20 years of the IT industry) they’ll probably try to prevent you from achieving it as much as possible.

The point is that it makes it damned hard to do certain work on linux (e.g. working on large MS Word documents, where you’re almost bound to encounter one or more of the things that don’t work in OO.org).
[/quote]
Don’t know if it’s that simple. I sometimes wonder how good Openoffice is at using MS formats. Maybe there should be more warnings, that it is better to use OOOs own formats, if there is no reason for using the MS formats. After all it was a good decision of Openoffice to support these formats to get into the market, although they have practically no chance to fully support them. Openoffice is a good interchange format, if several people on different platforms work on one document.

Btw. I don’t like people sending MS Office documents by mail. (more info)

#64

[quote]Jens, I have ‘tried it’ several times as well. My experience has been exactly like Cas’. Why don’t I use a Package? I try but they rarely install - they simply spew a message that you need a zillion other packages. Good luck finding them… Better luck finding the packages that they depend on. etc…
[/quote]
I guess I’m using Debian for too long time. Debian installs all the necessary packages automatically and there are more than 10000 maintained packages available, which means that you almost always find what you need and almost every package will integrate nicely in your KDE/Gnome/… menus. Nevertheless major packages like Openoffice and Mozilla should install painless in Redhat, Suse and Mandrake, too.

I know from using Suse and Redhat in the past it was often much more difficult to find the correct packages and the distributors theirself maintain a smaller number of packages than Debian does. Maybe this is really a problem for a large number of users. On the other hand I don’t think that Debian is especially Newbie-friendly. At least it doesn’t try to hide everything from the user. The installers asks a lot of questions (although you can almost always choose the default).

To summarize it: Suse/Redhat/Mandrake make it relatively easy to install a basic system, but it gets harder if you want to customize and extends the system. Debian is more complicate at the first glance, but is a joy to maintain. Another difference is that Suse/Redhat/Mandrake have relatively new packages in their stable release, while Debian stable has quite old software.

[quote]Cas’ comments about appalling UI is also true… applications have radically different behaviour and looks, a zillion different widget toolkits are in use all with their own quirks.
[/quote]
KDE and Gnome are the leading desktops, so you will mostly see either GTK or Qt style. Both are very nice and intuitive. Some apps even have both, a Qt and a KDE version, so that you can choose.

#65

Someone should have locked this thread along time ago…

It seems to me that princec was expecting to fail with his experiment;

  1. 800x600x32 is a bit aggressive even for directdraw (what I’ve seen at least) let alone ‘software rendered’ java2d and is that res really necessary for a lunar lander clone?

  2. If you took the time to implement software routines to do the blitting, blending, and fading it still would have been slow because of the res. (I’ve got a Surface class that does all these). But thats software, you expect that.

  3. I think your expectations (?) were way out of line with reality; how do your results with java2d differ from the results one could suppose you would have gotten trying to implement the same features with gdi? Or any other non-hardware acclerated api?

I think java2d, even with all the worts, is more than capable of doing classic 16 bit ‘console’ style games. And in that area, a fair degree of crossplatform uniformity/reliability may be possible. Thats were my interest lie. Obviously theres no market for games like that but they can be fun.

#66

Well, I really don’t see why anyone’s going to buy into a technology that enables them to just about emulate a Sega Megadrive on a 2GHz machine.

Actually, it’s an entirely reasonable resolution for DD, as DD just delegates the drawing to hardware. DD is in fact the same speed as OpenGL at blitting rectangles. What I’d like to know is why it’s still using DD, despite the fact M$ deprecated the entire DD API several versions ago because 3D hardware gives so much more flexibility.

This is precisely my point. There is no other API and therefore what you have got has got to be faster or it’s as much use as a chocolate fireguard. The design of the API has made it a little tricky in some respects to make it hardware friendly but I still believe that a switch to D3D could easily have been made, and we’d have accelerated alpha blending, finally. But we don’t (or if we do it requires arcane tricks).

I would stress here that I’m not knocking the functionality of the API - which is excellent - or the rendering quality - which is superb - or the windowing toolkit - which is adequate: I’m only concerned about the speed of blitting operations. I am, after all, a games programmer, and blitting is what interests me.

Cas :slight_smile:

#67

[quote]I think java2d, even with all the worts, is more than capable of doing classic 16 bit ‘console’ style games.
[/quote]
See my post earlier in the thread - you may be able to make 16-bit-like games, but AWT still isn’t as powerful as a Megadrive when it comes to blitting operation. When you think that that particular piece of hardware is now 15 years old, AWT just doesn’t cut it.

#68

[quote] you may be able to make 16-bit-like games, but AWT still isn’t as powerful as a Megadrive when it comes to blitting operation.
[/quote]
I don’t know what the resolution was on the Megadrive, but on snes and sega genesis it was very low (definitly less than 320x240) and only 8 bit color. Its very easy to surpass that hardware using per-pixel software operations with AWT; 32 bit color with alpha, etc etc…

I still think princec’s evaluation is a bit lopsided.

#69

IIRC, the MegaDrive was 320x200. So thats 320/8 + 200/8 = 1000 tiles per layer, and a maximum of 4 layers (or wasn’t there a ‘window’ layer as well that didn’t scroll?) Thats 4000 blit operations before you’ve even added any sprites, try that in AWT and it’ll gag, splutter and crawl. And thats straight blitting, before you even consider things like shearing or rotation.

#70

[quote]320/8 * 200/8 = 1000
[/quote]
ru sure those numbers are right? :-/

Even with hardware acceleration, you will be lucky if you get more than 20000 blits/frame@30fps on my 1.33athlon/gf2gts :-/ (and thats without any sprites at all)

Is Java realy that slow?
or is it just that the modern PCs hardware isn’t specifically designed for fast blitting?

#71

Just to check, I dug out a MD emulator, and the res it runs at is 320x224 (although that probably varys a bit with PAL or NSTC). I’m pretty sure those numbers are in the right area, 8x8 tiles really are tiny, even at that kind of resolution.

Although console 2d hardware is a tad freaky from what little I know, blitting isn’t really done the same way. But the point is that this is old hardware that still performs better at this kind of thing than current stuff.

#72

Well, what am I managing in AF… (fx: counts on fingers) Typically about 400 blits for the background (which is bumpmapped and lit), maybe about 100 sprites, and another 100-200 or so smoke and blobby bits sprites. Thats about 700 sprites. Oh, and the control panel, drawn on top; that’s another 30 odd sprites when it’s full. And maybe 20-30 characters flying around the screen in bonus points and strap messages. 750 blits typically then (although what we’re really interested in is fillrate here) not counting overlaid special effects (strobes, for example, are a big blended rectangle drawn over the entire screen). All running at 60fps on a GF1 and 500MHz CPU or so, and the sprites are all alpha blended and scaled (although most of 'em are at 1:1).

If it weren’t for the blending operations the potential to draw 10,000 scaled, rotated sprites in a frame could be realised but we have to remember the megadrive and such don’t have alpha blending. And this isn’t the point! This is 15 years later, and I want to see progress!!! Not merely failing to achieve what could be done in the last millenium!

And of course, I forgot to mention this is in 16 bit colour at 800x600 - over thirteen times the resolution of a megadrive. Yet what can we achieve with AWT?..

Cas :slight_smile:

#73

[quote]IIRC, the MegaDrive was 320x200. So thats 320/8 + 200/8 = 1000 tiles per layer, and a maximum of 4 layers (or wasn’t there a ‘window’ layer as well that didn’t scroll?) Thats 4000 blit operations before you’ve even added any sprites, try that in AWT and it’ll gag, splutter and crawl. And thats straight blitting, before you even consider things like shearing or rotation.
[/quote]
Try that with direct draw and it’ll gag.

The architecture we have nowadays is completly different. Also the meaning of terms is now slightly different. 15 years ago a sprite was a fart of pixels like 2x16… and now a sprite is the whole thing (e.g. a character in a beat’em up [=dozes of 2x16 tiles]). Everything is just a bit more “high level”.

Ofcorse we won’t create a background out of 2x16 tiles and we won’t draw our “sprites” with 40+ blits.

Well have you guys compared the speed of awt with the speed of native direct draw programs? It’s the same speed. If you hit the fillrate limit of the graphics adapter, you’ve reached the machine’s limit - and that’s it. It won’t get any faster even if you use assembler.

And fullalpha is slow, because it’s done in software (ddraw just doesn’t support it).

Hmm… wasn’t there a project around (a year ago or so) wich allowed you to switch between java2d and opengl (lwjgl)? It was called blabla abstraction layer or so and Kevin (kevglass) was involved (and someone else) iirc.

What happend with it? :slight_smile:

#74

[quote] Hmm… wasn’t there a project around (a year ago or so) wich allowed you to switch between java2d and opengl (lwjgl)? It was called blabla abstraction layer or so and Kevin (kevglass) was involved (and someone else) iirc.
[/quote]
http://j2da.sf.net ?

#75

Ah there it is. Thank you :slight_smile:

#76

J2DA, yep, that it is/was. Its still hanging around but its fairly good illustration of the problems with OS. The source while ok isn’t being actively developed at the moment and so more than like is stagnating. Never got past a 0.2 release, although there has been a renewed interest recently, something might slowly come out of the ashes.

Incidently, it used JOGL for opengl (not that it really matters :)) tho we always had plans for the option of LWJGL.

Kev

#77

[quote] If it weren’t for the blending operations the potential to draw 10,000 scaled, rotated sprites in a frame could be realised but we have to remember the megadrive and such don’t have alpha blending. And this isn’t the point! This is 15 years later, and I want to see progress!!! Not merely failing to achieve what could be done in the last millenium!
[/quote]
And you have seen progress; in 3d acceleration! This is what I meant by lopsided; your looking for performance in AWT that you have no reason to expect to be there (?).

I’m confident you can get a 3 layer tile map + a bunch of sprites in AWT (@ 320x200x32) with at least 30 fps. I’d thow in a stretch draw using drawImage() too so its not such a freakishly small window.

#78

So if AWT is as fast as DirectDraw, then AWT is OK, no reason to flame it.

I conclude that using a 3D-API like OpenGL for your 2D game(s) is the fastest way to let do blits and alpha-transparency and such.
So what we need is an OpenGL native binding in J2SE which works on all platforms by default and is callable by the developers.

I vote: JOGL for J2SE.

#79

I vote LWJGL for J2SE :slight_smile:

Cas :slight_smile:

#80

I vote: one of em :stuck_out_tongue:

However, I would prefer LWJGL, but I would be also fine with JOGL.