Java-Gaming.org Hi !
Featured games (83)
games approved by the League of Dukes
Games in Showcase (526)
Games in Android Showcase (127)
games submitted by our members
Games in WIP (593)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
   Home   Help   Search   Login   Register   
  Show Posts
Pages: [1]
1  Java Game APIs & Engines / JInput / not registering spacebar when up and left is pressed on: 2008-03-05 05:03:39
I was writing a little app using Slick, and I came across this little issue. I thought for a while that it had something to do with my code, then I came across this:

http://www.newdawnsoftware.com/resources/jinput/webstart/jinput.jnlp

and was getting the same result: I would hold down up and left, and while both would register, pressing the spacebar doesn't when the up and left keys are held down. Anyone else come across this? I wonder if it's my keyboard - I'm on a Dell laptop (XPS M1210) running Vista
2  Discussions / General Discussions / Slick Discussion Forums down? on: 2008-03-04 05:59:15
I've tried to access the discussion forums over at http://slick.cokeandcode.com/ but it appears the forums are down.
3  Discussions / Miscellaneous Topics / Re: building my own computer on: 2004-05-07 21:54:53
My approach is different. I don't have a lot of money to spend, so I've always been buying gear on a budget. My aim isn't to get the newest hottest stuff that came out of the market, I simply can't afford it. Instead, I mostly look for stuff that is 3-6 months old. That way, it's neither so old it's obsolete, but also cheap enough to afford.

My suggestions on parts:

1) if you are going budget cpu, get an AMD chip. Don't bother wasting your money on intel. The Celerons are absolutely the most worthless chips on the market. So not worth it. You can get a pretty nice chip for less then $100. Granted, it's not gonna win any medals, but it'll get the job done. I still work on my Athlon 1.4 Ghz, it's chugging out a-ok.

2) Don't skimp out on ram. Get the most ram you can afford.  at the minimum, 512. More is better.  Faster is always better too, but I don't notice. I got pc2100, and I've been meaning to upgrade, but I've been lazy cause I feel there is no real need as of now. :-)

3) If you are looking for HD space, check the dollar/gig amount. (Only talking about IDE) I do all my shopping at newegg, and the cheapest I saw around 6-8 months ago were the 160 gig HD's. Samsung, Hitachi, Maxtor, WD all were around the same price, so whatever is your preference.  A quick search on newegg shows The WD HD for about almost 50 cents per gig.

4) Save money by getting a smaller SATA drive. I mostly use the SATA HD for apps, and the IDE drive for my 'files.' You could use that money saved to get a raid card and a second IDE drive to get your geek on. :-)

5) I *used* to play a lot of games, but not any as of lately (still meaning to get me a copy of KOTOR), so (to me) a video card is a video card is a video card.  I usually get the card that cost me $150 today, or 6 months from now.
Tongue A video card that costs me $150 today could still run EQ fine. But then again, I also play EQ with my on-board mobo video...

So save your money. You will always be upgrading in the future anyway, it's not that big a deal to get the newest stuff.  Cheesy

As for myself, the next computer I'm getting is a G5.  Wink

Or a powerbook, I haven't decided yet.
4  Java Game APIs & Engines / Java 2D / Re: Preloading Graphics on: 2004-04-12 02:59:30
Newbie disclaimer - I'm not a coder, I don't code professionally, in fact you may grit your teeth to find out what I do for a living. Anyways, you guys are warned.  Grin

I'm assuming the idea that a loading screen is necessary is because the process is blocking because it's busy doing io. Therefore, when you go to the 'next stage,' the game does all the IO before the gameplaying stage to keep the game playing pace, err playable.

If you try to callup IO to load up MonsterSpriteA into your game every time MonsterA is walking into your screen, you will always receive a 'hiccup' in the gamepace right before the monster strolls onscreen, and everybody will find that annoying (and predictable). The smaller the file, the smaller the hiccup.  (are my assumptions correct?)

However, how about if you use a different thread to make IO calls, and have the thread pass over the object whenever it is good and ready? That way, your gamethread can keep playing along, and not worry about blocking due to IO.  The downside to this is, that you can't have that thread make the calls on the fly, because it will still take time for that new thread to grab the image. What would probably end up resulting is that the game thread simply shows 'nothing', or rather, an invisible object pummelling you and you having no idea why, because the other thread is still loading the sprite.  Or null pointer crashing (more or less, but you get the idea)

However, if you can 'foreshadow' the coming of the sprite, such as a tree graphic or whatnot, then you could have it loading up in your thread while you were walking over there, so by the time you get to the tree, the img will be loaded and will display it correctly.

This would be real handy for online games, where users can upload their custom sprites (avatars?) to the server, and upload it on the fly to clients that need to view it. Almost like a... browser with game rules.  Tongue

So, the real trick is not how you can load images, but rather *when* you can load the images. If it's like a zelda clone, where you can walk to a different part of town, if you know that you are within a certain distance to that unique looking tree, start grabbing the tree image so that by the time you get there, the tree will render on screen. Should you do it when you are one screen width's away from the tree? How fast does the screen scroll towards the three? How much time can you afford to loading time?

I've been thinking about a very very simple graphic mud client with display of 320*240 (think Old School Nintendo graphics), storing most of the graphics locally, downloading changes on the fly when necessary like a browser cache (small screen real estate helps my situation). The reasoning is that I could get rid of the idea of zones, and have the whole world in one big giant map, and the main loading time for the majority of the files would only be when you start up the game.

That's the gist, apologies if this whole post offers no real value.  Oh yeah, and is it possible to devote a seperate thread to disk IO like stated above in the first place?
Pages: [1]
 

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

The first screenshot will be displayed as a thumbnail.

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

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

toopeicgaming1999 (15 views)
2014-11-26 15:20:08

SHC (29 views)
2014-11-25 12:00:59

SHC (27 views)
2014-11-25 11:53:45

Norakomi (32 views)
2014-11-25 11:26:43

Gibbo3771 (27 views)
2014-11-24 19:59:16

trollwarrior1 (40 views)
2014-11-22 12:13:56

xFryIx (78 views)
2014-11-13 12:34:49

digdugdiggy (56 views)
2014-11-12 21:11:50
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!