Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Catloaf]

And farming involves many tasks.

[Royal☭]

Also when is the last time you tried open heart surgery on yourself?



It wasn't as easy as the guy on the video made it out to be.

[Arc]

the thing has to be staring me in the face at all times

..



...

[Bongo Bill]

And you're telling me farming is easy, vidya boy?

No. Just that it is easier to invent than surgery.

[Catloaf]

As suggested by Brentai, I'm posting in here.

I have very little experience with GUI/event based stuff, well I've gone over all the conceptual stuff about it, but I don't know any of the code, which should be in java, or at least in something similar enough to easily translate into java. 

I have two main problems:
1) Updatding, rendering, and outputting to screen.  This is the most important stuff for animation and I'm just not sure how to do it without stealing code.  And I can't find good code to steal either.

2)I just need to see what a proper implementation of a KeyListener in java looks like.  As I've only seen it once, when I wasn't near any place I could code, I can't do anything but try a stab in the dark and inevitably get a syntax error.


I am really hating being in this limbo of knowing exactly what commands I want to code, but having no idea how to issue them.

[Cyan Prime]

Class Java1 extends JFrame implements KeyListener
{
    Java1(){
     
     addKeyListener(this);
    }

}

also, javagaming.org

[Brentai]

Oddly enough CyanPrime is probably the expert on this particular subject.

[Catloaf]

Wow, I feel stupid.  "this"...  Fuck, it seems so obvious now.

Also, thanks for the link.  It's precisely what I was looking for.

[Classic]

For the longest time I've thought that his native tongue wasn't English.

[Bongo Bill]

So some folk at Google invented a language, called Go (debugger called Ogle is forthcoming). Early, experimental languages with no way to target Windows are a dime a dozen, but this one's got enough of a pedigree behind it that it's attracting some interest. Just looking over the docs, it seems interesting.

It's aimed at systems development. A C substitute, like. Emphasis on performance and compiles to native code, but without pointer arithmetic or manual memory management. Type system is pretty interesting: rather than true polymorphism, it's got something like implicit interface inheritance (you could liken it to a static version of Python's duck typing) plus some syntactic sugar that simulates subclassing. Syntax is nothing to write home about; on the one hand it's designed to make it easier to use functions like the first-class objects they are, but on the other hand sometimes semicolons are whitespace and sometimes they're not.

Main draw seems to be the concurrency model, which is different enough from the standard ways of doing things that they invented a new word for 'em, "goroutines." Under the hood they're a lot cheaper than native threads, apparently. The central concept for them is to avoid sharing memory (which, I suppose, is still technically possible if you are indiscreet with where you send pointers) through the use of things called "channels." Stick data in 'em in one thread, suck it out in another. Having first-class support for the things is the main draw.

They've clearly got server-side web development in mind for this thing, if you look at what parts of the standard library are biggest and fanciest. It can't, as yet, link or be linked to any other language, but it does have a foreign function interface if you want to call something from a C library. There's also an incomplete package in the standard library that looks like they'll be making an interactive parser for it. And another one that looks like Spacewar! will come as a standard feature eventually.

All in all it looks very modern, and by reports stable enough to get some useful things working right now, if you don't mind that the only libraries not built into the language are C libraries invoked through the foreign function interface. People are already hard at work trying to extend the standard library, though. It's young enough that patches will probably be accepted quickly.

[Cyan Prime]

Cool, now I don't have to add the variable "type" to my enemies!

Code: [Select]

if(enemies[0].getClass().toString().contains("Enemy1"))
    System.out.println(enemies[0].getClass().toString());


[Bongo Bill]

Using reflection when you don't have to is not considered idiomatic, not least because the performance is significantly worse. Performance does still matter in a few contexts, among them game programming. Doing it that way will also make refactoring a nightmare, if that's something you're concerned about.

The most advisable way to implement certain behavior in a program would be to consider the language features available, and determine how they might best be used to achieve your intention, rather than starting with an approach to the problem and searching for a language feature that permits you to implement a solution that works that way, as you seem to have done.

You seem to be looking for a way to make objects of various but unknown classes (or, rather, various but unknown subclasses of a known and presumably arbitrary superclass) exhibit differing behavior. It so happens that Java has a very fundamental language feature that is perfectly suited to this design! Simply override the superclass' methods, so that each subclass defines its own correct behavior, freeing the caller from having to determine which subclass it's dealing with.

Of course, if you just need to make a quick, dirty decision once in the program, then reflection can be an efficient, if sloppy, way to avoid having to add a new method to the superclass and all the relevant subclasses. Overreliance on this trick, however, will leave you with all the weaknesses of object orientation, all the ugliness of spaghetti code, and all the slowness of reflection. Not exactly a winning combination.

Play to the language's strengths, and understand not just what the features are and how they work, but why they exist and what idioms they suggest.

[Cyan Prime]

True, but the main problem with just updating is that I need it to do this:

Code: [Select]

if(enemies[i].getClass().toString().contains("Enemy1"))
    enemies[i].update(map);
   
if(enemies[i].getClass().toString().contains("Enemy2"))
    enemies[i].update(map, player);

I could just have it pass a player variable to the first kind of update too, but that seems like a waste of processing power.

[Bongo Bill]

...I... how... you...

Okay.

First of all, passing an extra parameter to a function costs next to nothing in terms of time, and you're not dealing with big enough objects for its space cost to be any kind of risk. It's particularly negligible next to the comparatively glacial reflection and string parsing. So don't worry about it.

As Dijkstra said, premature optimization is the root of all evil: you tried to squeeze a few nanoseconds' worth of speed out of your construct, and in so doing you tore down the scaffolding of your program; then, when the structure wasn't there when you needed it, you kludged together something that takes more time for a single operation than all those nanoseconds would have added up to in all the executions of your program over your entire lifetime. Evil!

I assume that Enemy1 and Enemy2 both share an ancestor, yes? And that it's called Enemy? Declare update in that class to accept a map and a player, and then define update in Enemy1, Enemy2, and whatever other subclasses to do whatever it needs with those arguments, regardless of whether it actually uses both of them. That is, Enemy1.update and Enemy2.update should respectively contain everything that an Enemy1 or an Enemy2 needs to do. Put that decision-making in the classes where it belongs.

Then in your main loop, you just have

Code: [Select]

enemies[i].update(map,player);That's as tight as tight can be, and it will run better. Maybe even noticeably better, if you're testing it on a slow enough machine or if enemies is big enough.

[Catloaf]

premature optimization is the root of all evil

Oh if only I had realized this earlier.  I wouldn't of had half the headaches I've had with game programming.

The half about java having way too many possible ways of handling graphics, none of which do exactly what I want them to do would still be there, however.

[Cyan Prime]

premature optimization is the root of all evil

Oh if only I had realized this earlier.  I wouldn't of had half the headaches I've had with game programming.

The half about java having way too many possible ways of handling graphics, none of which do exactly what I want them to do would still be there, however.

Catloaf, You should try using the lib Slick. It's the best 2D lib out there.

[Cyan Prime]

...I... how... you...

Okay.

First of all, passing an extra parameter to a function costs next to nothing in terms of time, and you're not dealing with big enough objects for its space cost to be any kind of risk. It's particularly negligible next to the comparatively glacial reflection and string parsing. So don't worry about it.

As Dijkstra said, premature optimization is the root of all evil: you tried to squeeze a few nanoseconds' worth of speed out of your construct, and in so doing you tore down the scaffolding of your program; then, when the structure wasn't there when you needed it, you kludged together something that takes more time for a single operation than all those nanoseconds would have added up to in all the executions of your program over your entire lifetime. Evil!

I assume that Enemy1 and Enemy2 both share an ancestor, yes? And that it's called Enemy? Declare update in that class to accept a map and a player, and then define update in Enemy1, Enemy2, and whatever other subclasses to do whatever it needs with those arguments, regardless of whether it actually uses both of them. That is, Enemy1.update and Enemy2.update should respectively contain everything that an Enemy1 or an Enemy2 needs to do. Put that decision-making in the classes where it belongs.

Then in your main loop, you just have

Code: [Select]

enemies[i].update(map,player);That's as tight as tight can be, and it will run better. Maybe even noticeably better, if you're testing it on a slow enough machine or if enemies is big enough.

Ah, alright. Thanks for the info 

[Catloaf]

premature optimization is the root of all evil

Oh if only I had realized this earlier.  I wouldn't of had half the headaches I've had with game programming.

The half about java having way too many possible ways of handling graphics, none of which do exactly what I want them to do would still be there, however.

Catloaf, You should try using the lib Slick. It's the best 2D lib out there.

I'd love to, but I have no idea how to add external libraries.  I need a goddamn file to install that shit for me, damn it!  And if/when you explain it, please note which IDE you're talking about.  Because I have netbeans and eclipse, and I have tried an failed to add slick to both already.

EDIT:  WOO I found the tutorials on how the hell to load it into eclipse!  So now I just have to familiarize myself with the library and then start coding!

[JDigital]

As Dijkstra said, premature optimization is the root of all evil

Dijkstra said Hoare said it, but Hoare is pretty sure Knuth said it.

I bet Dijkstra said it too though, and he has a cooler name.

[Brentai]

I've actually had pretty good luck with early optimization, but then I'm very smart.