Java-Gaming.org Hi !
Featured games (83)
games approved by the League of Dukes
Games in Showcase (538)
Games in Android Showcase (132)
games submitted by our members
Games in WIP (600)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1] 2
  ignore  |  Print  
  Programming 2.5D  (Read 5258 times)
0 Members and 1 Guest are viewing this topic.
Offline Dae

Senior Newbie





« Posted 2007-05-25 11:36:34 »

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.

Thanks much!
Offline CaptainJester

JGO Knight


Medals: 12
Projects: 2
Exp: 14 years


Make it work; make it better.


« Reply #1 - Posted 2007-05-25 12:04:34 »

Don't use an applet.  You can create an application and use Webstart so all the user has to do is click on a link and everything will be taken care of.

If you just want to use normal Java2D graphics, then there is nothing extra you have to do to get it to run.

If you want to use Fullscreen mode or use a library that uses native code, like LWJGL, then you need to sign your jar file that contains your application and the user will be prompted to accept your signed application.  Don't worry about this though, because if you start to sell your game, then you can afford a trusted digital certificate.

Slick is a 2D library built on top of LWJGL.  So you the performance of 3D with the ease of 2D.  It might be what you want to use for your game.

Offline erikd

JGO Ninja


Medals: 16
Projects: 4
Exp: 14 years


Maximumisness


« Reply #2 - Posted 2007-05-25 13:12:26 »

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.

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.

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Dae

Senior Newbie





« Reply #3 - Posted 2007-05-25 14:06:34 »

Thanks for the information CaptainJester.

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

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.


Offline Dae

Senior Newbie





« Reply #4 - Posted 2007-05-25 14:17:10 »

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.

Oh okay, so I should plan for Java 1.4 or higher then?

RuneScape runs on Java 1.1, lol Huh
Offline erikd

JGO Ninja


Medals: 16
Projects: 4
Exp: 14 years


Maximumisness


« Reply #5 - Posted 2007-05-25 14:27:12 »

Oh okay, so I should plan for Java 1.4 or higher then?

Yes, target at least java 1.4. It's also quite a safe bet these days.
And LWJGL at least needs java 1.4 or higher, it won't work with 1.2.

Quote
RuneScape runs on Java 1.1, lol Huh
Yes, back then it made sense as there was this hideous MS VM installed everywhere which only supported 1.1.
Nowadays it doesn't make much sense anymore to target this old version, as MS doesn't support their VM anymore, and the Sun JVM is usually the one that's installed.

Offline erikd

JGO Ninja


Medals: 16
Projects: 4
Exp: 14 years


Maximumisness


« Reply #6 - Posted 2007-05-25 14:32:44 »

By the way, and just to be sure  (just looking at your screenshot): My comments about using Java2D for creating 2.5D were thinking that you just use image scaling/zooming for creating your 3D look. No real 3D textured polygons or anything.

Offline Dae

Senior Newbie





« Reply #7 - Posted 2007-05-25 14:46:58 »

Great, thanks erikd. It's still amazing it runs on 1.1 though eh? Imagine if they upgraded to 1.4 and improved their engine.

Oh, no I won't be using 3D. I was just comparing it with RuneScape because it's the best (and only) example out there.

Graphics wise I'd be shooting for something like Diablo 2, or maybe lower. It uses DirectDraw 7 (option of Direct3D).



Offline Dae

Senior Newbie





« Reply #8 - Posted 2007-05-25 15:14:55 »

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.
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #9 - Posted 2007-05-25 15:58:11 »

I don't think a Java applet is capable of graphics close to Diablo 2...

I can absolutely guarantee you that java applets are capable of it Smiley.

malloc will be first against the wall when the revolution comes...
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Dae

Senior Newbie





« Reply #10 - Posted 2007-05-25 16:49:45 »

I can absolutely guarantee you that java applets are capable of it Smiley.

Time to get cracking then eh Smiley

Just to clarify, capable with: LWJGL/Java2D on Java 1.4, without changing any Java Sun variables to allow  the applet more RAM, and still running at 20 FPS or more?

Hahaha Cheesy

Oh and which one has more 2D applet support, LWJGL or JOGL?

Thanks
Offline Eliwood

Junior Devvie




Stencyl


« Reply #11 - Posted 2007-05-26 16:45:43 »

Time to get cracking then eh Smiley

Just to clarify, capable with: LWJGL/Java2D on Java 1.4, without changing any Java Sun variables to allow  the applet more RAM, and still running at 20 FPS or more?

Hahaha Cheesy

Oh and which one has more 2D applet support, LWJGL or JOGL?

Thanks

Any setup unless it's Windows 98 era (400 MHz, 128 MB, no video card) is more than capable of rendering 60 FPS for a reasonable LWJGL-powered game. The days of Java being "slow" are long past us.

- Jon

Offline Dae

Senior Newbie





« Reply #12 - Posted 2007-05-26 19:37:27 »

Any setup unless it's Windows 98 era (400 MHz, 128 MB, no video card) is more than capable of rendering 60 FPS for a reasonable LWJGL-powered game. The days of Java being "slow" are long past us.

- Jon

Great thanks Smiley I just wasn't sure how reasonable the above game (screenshots) on an applet would be.
Offline Matzon

JGO Knight


Medals: 19
Projects: 1


I'm gonna wring your pants!


« Reply #13 - Posted 2007-05-27 07:57:34 »

I can absolutely guarantee you that java applets are capable of it Smiley.
but I wouldn't recommend it!
There is a 128 MB heap limit in applets which blows for any big game like diablo.

Offline Dae

Senior Newbie





« Reply #14 - Posted 2007-05-27 13:15:13 »

128MB eh? Okay thanks Smiley

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?

Thanks again for the help fellas!
Offline Abuse

JGO Knight


Medals: 14


falling into the abyss of reality


« Reply #15 - Posted 2007-05-27 14:13:21 »

I'd wager Diablo2 also used palettized 8bpp images.

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.

Make Elite IV:Dangerous happen! Pledge your backing at KICKSTARTER here! https://dl.dropbox.com/u/54785909/EliteIVsmaller.png
Offline Dae

Senior Newbie





« Reply #16 - Posted 2007-05-27 14:19:27 »

I'd wager Diablo2 also used palettized 8bpp images.

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.
Offline Eliwood

Junior Devvie




Stencyl


« Reply #17 - Posted 2007-05-27 16:40:33 »

Does it *have* to be an applet? Are you open to a WebStart app instead where the requirements are less stringent?

If you have to stick to applet, use LWJGL, and manage your memory carefully, and you should be able to squeeze it out.

- Jon

Offline Dae

Senior Newbie





« Reply #18 - Posted 2007-05-27 16:56:30 »

Yeah, it *has* to be an applet. Otherwise I would stick to 3D with C++.

Who knows though, I might change my mind in the future and go with a download or WebStart. I'd only have to change the client.

It'll be tough but I'll do my best memory managing. Smiley

Edit: I'm about to say screw it and not use an applet. But why even use Java then? Lips Sealed

Edit: Would be a good idea to allow more memory usage for digitally certified applications. That removes the issue of allowing any random applet to use tons of memory.

Edit: Do you think by the time I finish the game, around 3 years, they would have increase the memory an applet can use? Have they done that before?
Offline Matzon

JGO Knight


Medals: 19
Projects: 1


I'm gonna wring your pants!


« Reply #19 - Posted 2007-05-27 19:00:05 »

You'll probably start getting OutOfMemoryError's all over the place. Do keep in mind that the runtime probably starts with sucking up 25MB+.
Consider using Java Webstart instead.

Offline Dae

Senior Newbie





« Reply #20 - Posted 2007-05-27 23:22:05 »

Is there much of a difference between 5 and 6 for games? because Windows XP comes with 5 I think.

When we're talking about memory, that doesn't include images right? That's just stored in your video card memory correct?
Offline Abuse

JGO Knight


Medals: 14


falling into the abyss of reality


« Reply #21 - Posted 2007-05-28 01:01:46 »

Is there much of a difference between 5 and 6 for games? because Windows XP comes with 5 I think.

When we're talking about memory, that doesn't include images right? That's just stored in your video card memory correct?

5 or 6 what?

IE5/6 ? or Java 5/6?

WinXP (without service packs) comes with IE 6, and the crappy 1.1x M$ JVM.

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)

Make Elite IV:Dangerous happen! Pledge your backing at KICKSTARTER here! https://dl.dropbox.com/u/54785909/EliteIVsmaller.png
Offline Dae

Senior Newbie





« Reply #22 - Posted 2007-05-28 01:48:45 »

5 or 6 what?

IE5/6 ? or Java 5/6?

WinXP (without service packs) comes with IE 6, and the crappy 1.1x M$ JVM.

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)

Java 5/6 (browser makes no difference "for games")
Offline Dae

Senior Newbie





« Reply #23 - Posted 2007-05-28 05:07:33 »

So no matter what the applet is using the 125MB ram allowed as backup images for the vram?

That's horrible for 2D games, images take up too much memory for me to be using my 125MB ram on them.

So what the hell.. if I store an image (say jpeg) to a variable in the 125MB ram, and render it, then does the video card in turn make a backup on the 125MB ram again? Huh

If no, then what if I store the image in a byte array and create the image?

If vram really does use part of my 125MB ram as backup then there's no way an applet is capable for a 2D game of that magnitude. Undecided

Thanks
Offline Riven
« League of Dukes »

« JGO Overlord »


Medals: 840
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #24 - Posted 2007-05-28 10:37:06 »

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.

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social
Offline Dae

Senior Newbie





« Reply #25 - Posted 2007-05-28 16:44:37 »

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.
Offline Riven
« League of Dukes »

« JGO Overlord »


Medals: 840
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #26 - Posted 2007-05-28 18:01:48 »

Check your private messages. Use at your own risk.

No, there are no tutorials, no official wrappers, no support, highly discouraged.

It basicly lets you use pointers. Nothing more, nothing less.

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social
Offline Dae

Senior Newbie





« Reply #27 - Posted 2007-05-28 18:43:29 »

Well, it looks like C, which is safe if you're very careful.

Quote
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 Smiley
Offline Riven
« League of Dukes »

« JGO Overlord »


Medals: 840
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #28 - Posted 2007-05-28 18:54:29 »

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.

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social
Offline Dae

Senior Newbie





« Reply #29 - Posted 2007-05-28 19:39:17 »

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?

P.S.
Weird, I only had 1 message, lol. I deleted it. ^_^
Pages: [1] 2
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

rwatson462 (28 views)
2014-12-15 09:26:44

Mr.CodeIt (19 views)
2014-12-14 19:50:38

BurntPizza (37 views)
2014-12-09 22:41:13

BurntPizza (72 views)
2014-12-08 04:46:31

JscottyBieshaar (34 views)
2014-12-05 12:39:02

SHC (46 views)
2014-12-03 16:27:13

CopyableCougar4 (42 views)
2014-11-29 21:32:03

toopeicgaming1999 (110 views)
2014-11-26 15:22:04

toopeicgaming1999 (96 views)
2014-11-26 15:20:36

toopeicgaming1999 (29 views)
2014-11-26 15:20:08
Understanding relations between setOrigin, setScale and setPosition in libGdx
by mbabuskov
2014-10-09 22:35:00

Definite guide to supporting multiple device resolutions on Android (2014)
by mbabuskov
2014-10-02 22:36:02

List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06
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
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!