Yes, you have to copy the data in the image yourself and put it somewhere, where you can retreive it and use it to restore the image in vram.

that 'somewhere' can be anywhere (if you're working with a byte[] to hold the data)I gave you some code to put it in your own malloc-ed memory block, where it shouldn't take any heap-space.The byte[] will be garbage collected eventually, so your heap stays relativly small.

P.S.Your mailbox is full.

Very nice, thanks again, Riven.

Unless anyone has more unsafe information, could someone please direct me to a decent server/client tutorial for Java 5.0/6.0?

Regarding memory, because graphics memory is considered to be volatile and apparently can lose it's contents at any point; images always have a backup of their contents in heap memory also, so if the vram cache of the image does become invalid, it can be restored.

I tried googling this and no luck. Could someone please elaborate on vram backups on ram? Is that part of my applets allocated memory? If I already have the image stored in memory will it still backup? Thank you very much

With sun.misc.Unsafe (insert horror-tune here) you can malloc 'unlimited' amounts of direct-memory. Wrap your own ByteBuffer around it and you're done.

You'll need a signed applet though.

sun.misc.Unsafe... All I've read is, essentially, it is the devil. LOL. People seem really scared. I welcome a nice little hack, but I'm used to C/C++. I don't care if it's undocumented or changes in future versions. As long as it works and isn't full of bugs. Is it that there's no 'bugs' in Sun's code, but you have to be careful or your script could have bugs?

Are there any wrappers, examples, or tutorials for this? In my case more memory is worth requiring it signed.

Regarding memory, because graphics memory is considered to be volatile and apparently can lose it's contents at any point; images always have a backup of their contents in heap memory also, so if the vram cache of the image does become invalid, it can be restored.Theoretically you could have a VolatileImage that was backed by a file containing the image data (rather than an in-memory representation), but it would have the potencial of being hideously slowly. (as there are no guarantees made on the frequency at which an image in vram might have to have its contents restored)

When compiling your Java code, you can specify the target version. So, you can use Java 6 to develop applets compatible with 1.4.2 if you are careful and if you don't use API calls that are marked with "@since 1.5" or "@since 1.6". Intellij IDEA automatically raises warnings in such cases but I think other Java IDEs aren't clever enough.

You can even develop using the syntax introduced with Java 5 and then use Retrotranslator to fix the class files.

I'd however go for Java 6 (preferable Consumer JRE edition) and hope that by the time I'm ready, there are enough users that have the current Java version installed. According to Adobe (who publishes distribution statistics for Flash - 98% overall, 85% latest version)) 85% of all browsers have Java installed but they don't tell you the version. AFAIK there are no other statistics available from Sun.

Thank you very much, sma! That was very informative, and I didn't even think of that. You're right, I should go for Java 6 and hope by the time I'm ready most people have upgraded.

Why do you want to download a 6+ years old JDK with an IDE that is probably of the same age? For development I'd recommend the latest SDK version 6u1 and the latest Netbeans IDE (6.0M9) or Eclipse (3.3RC1) or IDEA (7M1). If you want for some reason to test against that ancient version, use the JRE. Please notice that the JRE version bundled with Netbeans isn't the latest patch level and it might be vulnerable. I wouldn't recommend to install it.

Java2D's support for these image types is poor - as far as I understand, while they will be stored in this format in the heap, when they are cached in vram they will be expanded to 32bpp argb.

Also palette manipulation (which Diablo made extensive use of) will break the hardware acceleration pipeline.

If you are intending on making a Diablo clone, I'd suggest not using Java2D - the API is simply too inflexible to efficiently achieve what you want to do.There is nothing more frustrating than having to design around a limited capability API.

Aww okay, thanks man. I don't know anything about this yet, and that's exactly why I'm asking. So I learn the right API and procedures.

What about LWJGL or JOGL?

Sun should really allow applets more than 125MB, by default. Computers are much better nowadays and it just an unnecessary limit. 256MB or 512MB would be awesome.

D2 initially loads 35MB at menu, 50MB in game, 100MB after around 5 minutes. In single-player it stores everything that happened in that game. Since they used single-player as the base for multi-player it does the same on battle.net when it shouldn't. Meaning the server sends all the players in the game information on the game to store in memory even if they aren't in the same act, even close, or finished 5 minutes ago. After 15-20 minutes D2 finally frees the memory. Designing a multi-player game to begin with leaves me at an advantage because I should only have to use the client as a remote and for rendering/audio. So as they leave an area I can queue to free that memory. So I'm thinking the game show hover around 75MB, but under a huge load it could get up to 120MB. To test I started at 50MB in Act 5 and went and killed Shenk and all the surrounding areas. It got up to 85MB, and if they want to go anywhere the memory would be freed.

What do you think? What happens when it hits 125MB? Can I detect when it hits 120MB and disconnect the user?

I don't think a Java applet is capable of graphics close to Diablo 2... Maybe if a lot of detail is removed and theres more tiles. Even then the animations are very large and detailed. Of course there would be culling, and graphics would be downloaded on demand, it still seems like it might be too CPU/RAM intensive.

I can ask to "allow Game Name to store files on your computer" though right? So theres no re-downloading playing the second time.

If you want to use an applet, the easiest you can do is just use Java2D.I found that even on java 1.4 (at least on windows), the performance of drawing resized images can be good enough to do a 2.5D game, as long as you use 1-colour transparency for your images, not an alpha channel (i.e. use GIF's wi.

If you want a better chance of getting good performance across platforms (and good performance when using alpha channel), even on java 1.4, using Slick or straight OpenGL through LWJGL or JOGL is the way to go. It is possible to use LWJGL and JOGL in an applet, although I heard you could run into some compatibility problems on some browsers/OS-es, and it's all a bit more complicated to set up.

So that's how it works, that verification popup can be removed if you buy a trusted digital certificate eh, that's nice.

Sorry I didn't mention this, but it must be an applet. Eventually I'd like to make a multi-player, and want it as seamless and compatible as possible.

I read LWJGL now works with applets, but is it very limited and not worth using over Java2D for applets? I also want to consider compatibility, and I read LWJGL will work on JDK 1.2 and JVM.

Ohh, I see, I'd be overloading the applet, even if it was single-player? Even though I didn't want to start with multi-player, I might have to, for these purposes. So perhaps I should make a simple server/client first, the Java server does the hard work and sends the results to the Java applet client.

Well, if I were to use a web-start then that would *require* Java Sun (JDK 1.4.1 too I think).

If I learned anything from Flash it was that most people use outdated software. So in Flash if you want your app to be compatible with most people without sending them to manually download and install, you design for the older versions. We're up to Flash 9, and professionals still make websites in Flash 6.

Slick looks great, but still in the lower stages of development. I'd have a big problem if it was buggy and they slowed down or stopped development wouldn't I? I pretty much want to start from scratch as low-level as possible.

RuneScape runs on your default java client, MS or SUN. Looking at it more, it actually does use some hefty textures (and all that 3D rendering). I was afraid it would require too much downloading (loading) to use 2.5D.

Hey, I wanna start learning Java in order to create a 2.5D game, which is like 2D images creating a 'fake' 3D look. I can't figure out what I should be using though.

First of all, I want it applet based so people don't have to manually download. They should be able to simply run it in most browsers on most systems.

With that in mind would I only be able to use pure Java and Swing? or can I use Java2D or LWJGL ? or would those not run on their computer unless they manually install them (like with Java3D)? or would it just require a verification screen? and if I can use Java2D and LWJGL, which should I use? LWJGL's OpenGL for most of it I'm thinking? Should be *some* lighting, shadows (but I think I can do that manually), transparency, and a lot of graphics.

Hi, I just signed up. These forums look great, hopefully I'm stickin around.

I'd like to start game programming and I've been exploring my options. I've got some C++, Java, PHP, MySQL, and Flash experience.

I'm not going to straight out say I want to help create an MMOG, but I want it to be an option. I want to know Java is capable.

The goal would be a 2.5D (not 3D, 'fake' 3D using 2D - Quake, Duke Nukem, Diablo, Sacred) MMOG applet. Until I'm ready I can learn, make demos, and perhaps not dab into applets/databases yet.

I know Java is capable of MMOGs, but what about applet MMOGs?

There's RuneScape, which is a 3D MMORPG applet programming in pure Java, and a Java server-side on Linux. I don't really like the game but it seems to me they're the only ones to have accomplished a MMOG applet. It's also programmed well so there's virtually no hacks.

However that game is 3D, and I'm interested in 2.5D. It's an applet, so I don't want some huge download, or a loading screen too excessive. Of course there would be no problem if I made the users download say 400MB worth of graphics in order to play - but IMO that defeats the purpose. Would using 2D graphics for the entire game be worse than 3D? They could be lower quality, like 2000 game graphics. There could be loading screens for dungeons, cities, and inbetween large areas.

Anyway do you think a Java applet would be able to run that smooth with that kind of imagery thrown at it? It shouldn't be unbearable for those without high speed broadband. Hell, it should run smooth on broadband. Would it?

Thanks

Edit: The game files are stored on the players computer in the background as they are downloaded. Are they purely temporary or can they be made permanent? If they stay there, then after the player say finishes the game they would have all the graphics stored on their computer and wouldn't have to redownload them in the future. So they only have a loading screen the first time exploring that area. No? God that would be sweet... Like streaming video, but a game ^^

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