Yeah- placeholders! No point faffing around making sure every image is perfect until the design is settled on. Stuff is just copy/pasted from places until you're sure how you want it...

Quote

The fonts don't smooth themselves at all on my computer either, I wonder why.

If you're using MSIE, this appears to be a problem with windows + MSIE + the "Impact" font. I can't check other OS's, since Impact is a windows-only one - but it looks a lot nicer that just plain sans.

I like the new layout too, except for the use of the <legend> tags. I mean, they look good because of the text being right with the border and all, but there's no way to control the color (that I know of) through CSS or anything. the color of the <legend> text depends on the OS's theme (and with windows XP blue theme, blue text doesnt go so great with that background...)

I'd like the "New games" and "Best games" to be on the right, though, as having them on the left implies they're there for navigation purposes. I also think they're a bit too large. I'm surfing at 1600*1200, so no problem here, but it would be if I were surfing at 800*600. Just slim down the gfx a bit, and move them over. I really like the new colour-scheme.

I like the new layout too, except for the use of the <legend> tags. I mean, they look good because of the text being right with the border and all, but there's no way to control the color (that I know of) through CSS or anything. the color of the <legend> text depends on the OS's theme (and with windows XP blue theme, blue text doesnt go so great with that background...)

I get a white background in both Firefox and IE. The text in question does show up blue in IE, but in Firefox it is black.

I might have to set up a version like that so you can see, but ... it just looked WEIRD with them on the right. I can't explain it. Best I could come up with was that mostly you read the LH edge of the main content (you read the news title, NOT the date, etc), and so in the present scheme you are close to reading down the centre of the screen, but in the other way around you end up reading down the extreme left edge of screen.

Howabout you hang on a bit, give me time to make some other pages in this style, and link them in. Then, when you've got 4 or 5 linked together, see what you think, and re-comment on the left/right handedness?

Other than that, I see what you mean - I originally did it the other side, but it looked so bad I switched it.

Quote

I also think they're a bit too large. I'm surfing

I'm *not* designing for 800. It's so unfair on the people with 1200 or greater - or on the designer, to have to make compeltely separate copies of the same source for different res's . I mainly aim at 1024, which is now almost universal (save for the 10% or so of exceptions).

re: size, part of the problem is that I haven't overlaid the screenshots . Each grey rounded-rect will have a screenshot inside it, taking up almost the entire thing. The sizes make more sense one you see it like that (sorry, only have it setup like that on my home LAN at the moment).

Also, this is the front page you'll see when you type "http://javagamesfactory.org", so it's intended to be simple and REALLY easy to find the games. The "top 5 games" will intially be admin-selected and rotated, so we can guarantee they are genuinely *good* - big fat welcome to give a good impression. Once you link off this page into the "all games" pages, things will be less gigantic (I think; but I only have rough sketches so far, so I'm not sure yet).

Also, it's about expectations. I checked out 20 of the main "competitors". Look at popcap.com for possibly the most extreme example. A *lot* of people play popcap.

The font also looks pretty bad in win+firefox. Impact looks only good for really big text.

I've never seen <legend> tags before... in my case the text is just black. Uhm.

. Fonts + web == sucks. Even now, ten years after I first made that statement to someone when I was first doing websites, it's almost no better. Sob. I don't have the time to make anti-aliased/smoothed GIF's (remember, folks: MSIE doesn't support PNG!) for each and every H1, H2, H3 (those are the things using IMPACT, with some styling tricks layered over them), so it won't happen unless someone else does it (and maintains it).

I don't want to have to remove Impact entirely, because side-by-side with sans it really does complement the rest of the page much better (when rendered tolerably!).

If you've nothing better to do with it, send it over. The paypal account is now being held "in reserve". Firstly, if anything happens to the Agency9 donated server, we'll need that money *immediately* to get a new, commercial, server ASAP. Secondly, if the server remains fine, the money will be used for general community-support.

For instance, ideas suggested so far include: - purchasing prizes to give away in programming competitions - bribes to get vendors to give JGF users discounts, or e.g. to get professional sound-companies to give-away, exclusive to JGF java games (which, of course, anyone can make), subsets of some of their commercial sound effects.

Better ideas are welcomed .

I'll still be trying to negotiate freebies for competitions and so on, e.g. programming books, e.g. Java branded stuff, etc - but being able to *buy* something really useful is always helpful in case that doesn't work.

I guarantee the money won't be used for anything non-community-related ("community" == java games developers). When (eventually!) we get some kind of forums set up, I'll make a forum for suggestions for good uses...

Sob, sob. RFC 1867 is a PITA. I'm struggling to find a way to implement it with some semblence of efficiency. Unfortunately, *unlike HTTP*, this RFC doesn't tell you in advance how many bytes there are in each upload - so there appears to be NO WAY of streaming data from the network card direct to disk.

Since we'll be having incoming uploads regularly of 5Mb - 10Mb this *really* ****es me off. I'm going to have to read every damn byte of every damn upload just to find the end-of-file!

Argh! Any suggestions for how to get around this would be gratefully received.

I might instead just do something really irritating, like copy SourceForge.net's annoying system (hey, at least I now know why the heck they have such an annoying system!): create a dedicated FTP site where you have to upload your files, then you have to go to a page on the website that asks for the names of the files you upload (which you have to choose from a list of recently uploaded ones), and then the server has to move them out of the FTP directory and into wherever it actually needs them.

But I'm not sure we can risk that - the chance of someone deciding to use it as a porn-distributing-server etc.

RFC 1867 defines that file upload should not be done using x-www-url-encoded (or whatever the name for the default for forms is), but instead should use a MIME application/multi-part which is a protocol invented for email servers for sending an email with attachments (and also for sending multiple versions of the same email, e.g. HTML and plaintext, all at once).

Mozilla refuses to upload a file AT ALL if you don't tell it to use the MIME upload, and I suspect it does that because MSIE does it that way (although I haven't checked yet).

Even with the www-encoded type, you STILL wouldn't know where the file ends because there could be an arbitrary number of "&name=value" form inputs tacked on the end - thre's no standard that says what order the browser MUST submit forms in, other than that most just submit the data in the order it appears in the HTML doc (and MSIE doesn't implement forms according to the HTML 4 spec anyway).

The "so simple even Homer would have thought of it" way of doing 1867 would seem to me to be to put a separate content-length on each and every element. But they didn't do that. Bastards.

Interesting link, thanks. But, AFAICS, they're just reading every byte into memory, and then as soon as the buffer is full they dump the buffer to disk and then further reads into memory are re-written into the disk.

It relies on J2EE's servlets, which provide only an InputStream. So at the very best it's not going to be any better than rolling my own, and it would require implementing lots of servlet interfaces just to get the Apache stuff to work. Might also have problems interfacing it with the incoming NBIO.

Eventually, after talking around a lot, I accepted that I was being overly conservative (or, if you prefer, an idiot) to think that such inefficiencies were going to be a problem with uploads. Sure, we can get thousands of hits a minute, but we're not going to be getting thousands of uploads a minute.

So, with HTTP upload out of the way, we're very very nearly there with being able to submit games and host them on the server, all automated. Phew.

then click on "tutorials" and "view proposals". Apologies for all the adjacent dead links - I'm testing rendering of the same layout in different browsers at the moment, so I need to stuff the pages with content to check layout (you wouldn't believe how different Mozilla, Opera, and MSIE are even in 2004...).

The front page explains how to get to the current JGF whilst the test server is still being tested, but the test server is getting quite usable (note: no games yet) so I want to get rid of the ugly IP address. Also need to test some DNS config stuff with the site.

Anyway, JGF is very nearly ready now. There's a couple of outstanding major bugs (some pages don't work at all on MSIE 6, the spawn of Satan; some article authors can't edit their own articles without the server deleting their text each time), and game submission isn't tested yet, but other than that it's good enough to go.

So...if the server would like to start working again (prayers and sacrifices to the gods of randomly breaking technology are encouraged) then you can expect to see JGF v3 very soon.

Is there a logo for JGF now? I'd quite like to a add a link/banner block to a couple of sites linking across...

Um, no. Unless you count the 3 words "java games factory" drawn at the top of the page in a plain font because web browsers are so crap (MSIE 6, I mean YOU!) at rendering large text at the same size and font and layout as each other.

It would be nice if someone would invent one...

Quote

For that matter, is there a link/banner block for JGO?

Um, what's that? Do you mean those thinks like the "Get java here" logo which Sun wants people to use to link to java download site?

If you put a "script... /script" tag into a webpage, it terminates the CSS processing at that point. If you put it close enough to the start of the file, it (sometimes) works. If you put it in an "onload" tag it often doesn't execute at all - unless it's in the first few thousand or so bytes of the file.

EDIT: This is PEBKAC: apparently, contrary to what any normal programmer would expect, you are only "allowed" one "onload" trigger in a single webpage - yet it's not an error to have others, they are just silently ignored. I *love* javascript

All formatting that contained that part of the page is terminated.

MSIE, embarassingly, doesn't have this bug.

Also, none of the "browser detect scripts" work with Mozilla;s current version. Don't ask me what Moz have changed, the scripts know it's "something NS-ish" and "gecko" but they can't tell it's Moz.

I am now...desperately...looking for a way to insert a link to a JNLP file using javascript that WORKS IN MOZILLA. Otherwise, we have to say goodbye to the otherwise exceptionally funky feature that if an MSIE visitor clicks on a game to play it, they automatically get Java 1.4+ installed and the game started automatically.

As always, any ideas are welcome. I've probably tried them all before, but it's worth asking just in case...

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