Win a copy of The Way of the Web Tester: A Beginner's Guide to Automating Tests this week in the Testing forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Components vs. Events to custom IO class

stylin sty
Posts: 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi All,
This is a long post so pass a few paragraphs to find the meat or move on
I have been tortured in by having my libraries pulled out from under my feet since 1984. Apple coding, Amiga coding, Microsoft WinG, DirectX, Java 1.1 awt, Swing, JFC...
I'm very reluctant to learn a new encyclopedia of knowledge about a language or a chunk of components unless I'm sure where I would stand with it.
My dream job came true- in 1998 I was working for Sony doing an online Java game (my applets:
But I never was content with the framwork of my applets.
In the C days it was easy- you just had arrays and a program that got large and nasty.
Then it got easier with C++ because you don't have to declare the same things as often yet you still get to have them since they are an offspring of a base class.
This opened a new can of worms for how code executes, combine this with placing the code in a multi-threaded operating system that passes events to specific functions and more arguments of coding paradigms come about.
Now Microsoft and everyone else goes and makes multi-platform C++ video game and application development even harder by having the 'developer code to operating system programming interface' be non-standardized and proprietary (you don't find winprocmain()) on a mac... or macslametrs80() on a mac.) ))))()())
So thats why I went into Java.
Source code is not machine code.
It takes a machine to make any source code into its own machine code.
Therefore source code is universal-
it is the interpreter or compiler that can not be.
Java 1.1, having being installed on macs, PC's and running the same code find on both platforms proves that developers can agree on the compiler input and compiled program output.
The details of the machine specific code are irrelevant to everyone except for the programmers making the compiler.
If any one machine comes out with new hardware then commands should be added to the language to handle it. If your browser can not understand a command it does the usual all time hated update. (done right it would be less than 100k but for some reason winbloats like to make updates be 10000meg)
Critique this: (I am making statements here- any that you find false or true please comment on- be mean and frank or nice and agree- I need to learn fast)
1) All this swing, jfc, awt stuff is poorly developed crap.
2) If you want to make a 'real' applets (not a lame windowey looking one with plain text) you need to bail all the awt stuff and code your own stuff from the ground up (capture mouse events, key strokes, make keyboard classes, input boxes etc...)
Then you have to double buffer your whole app.
Once you do all this you are freed from the ever changing BS of 'lay out managers'
3) Developing Apps for more than one resolution is stupid.
It takes too much time to do the coding that puts gaps in your buttons to fill up the space- time needs to be put into code developement. And didn't your artist work hard on the display?
Why not just recompile 3 versions for high, med and low res when you are totally done?
(I'd have to disagree myself- I use programs and resize that thing all the time and I'm happy it fits stuff in the window)
4) So why use components over your own custom class?
5) Wouldn't mixing your own custom classes and components be the best?
6) What is this Jframe crap? Is it wrong to still use AWT?
7) What are the bad points of using AWT?

-Stylin Steve
Nathan Pruett
Posts: 4121
IntelliJ IDE Java Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

I kinda agree with you on points 1 and 2... JFC, Swing, and AWT are fine for things like database frontends, web forms, etc. but for games they look lame... it would be like developing a windows game in MFC... games need flashy interfaces. AWT, JFC, and MFC are for programs where the interface is secondary to the program. Layout managers are also a pain, but they help out alot when someone resizes your screen. I usually just subclass Canvas, Panel, or Component and draw my graphics directly to that.

As for point 3... it depends on the game... some games resize with no probs, some you need to lock to a certain size, and some you need to make sure they resize fine... I personally think that making 3 different versions of a game based on resolution is the 'lazy way out'.

Points 4 and 5... The only time to use a component is when you want a component and it doesn't matter how it looks... for some cases, you're just going to need a button to do something where function is more important than form... why take the time to develop a new 'Button' when the AWT button is fine?

Points 6 and 7. If you're developing applets, stick to AWT ( or AWT derived components )... Swing isn't supported directly by most browsers and requires a Plugin download by the user. Swing gives you way more components though... JTree, JTable, etc. and the 'upgraded' components look a bit better too... I think the biggest bad point of AWT is that each component has a native peer, whereas in Swing, only top-level components have native peers... Swing also has automatic double buffering, and supports way better graphics options, like dithering.

Hopefully, someday, I will be professionally developing games too... but right now it looks like I have to stick to making games in my 'free time'... which gets less and less as I 'pay the bills' doing 'professional' work...

Anyway, if you want, you can check out the only game I have online at this time... Catacombs!... a tetris clone... the graphics of this one were done by drawing images inside of a Panel. Wait a while once visiting the page for it to load... FortuneCity is slow and crappy... I've worked on lots of other games, but haven't really finished any of them...


P.S. - JavaRanch really likes names that agree with the JavaRanch name policy... Not all of us live in the 'fast-and-loose' world of game development ( ), and have to deal with corperate drudge like managers who have a hissy when developers are using the internet for anything other than 'professional' activities... by using real names ( or reasonable facsimiles thereof... ) in place of handles, it improves the image of ( i.e. - furthers the illusion of... ) JavaRanch as a 'professional' resource...
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic