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

I've tried to access the discussion forums over at http://slick.cokeandcode.com/ but it appears the forums are down.

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

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

Or a powerbook, I haven't decided yet.

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.  

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.  

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?