My First step towards new GraphicsAbstraction

[Shephiroth]

Used this system a long time ago, foe a DAO-Abstract develop. Should work here as well.

Now, for it to work, need to set Bitmap.abstractClassName to correct class checking OS. Also, if selected class didnt work, it load Default (the actual one).

The code is not tested, lot of error in class outside Screen package to compile. If you like the idea, ill get it compile.

DO NOT MERGE, still an idea.

[Maescool]

duplicate with #870?

[danielduner]

And of #858?

[Shephiroth]

im trying a better abstract implementation of the same idea. But dont call this "duplicate", 3 reasons: 1- Better abstraction, as you can see Bitmap class is almost abstract. 2- Not only abstraction, but a factory. You give a string, not a class. String that can be stored in file. String, that can change over time (Game modes?). 3- This system work for future uses, and future class, only need the string. 4- Portable. Work with graphics, work with sound, work with everything (as said, factory)

[Shephiroth]

why the reference??

[kylecbrodie]

@Shephiroth yeah ours are almost identical. If there are things of mine that you want to change, make a pull request to me and it will be added to #870. The only major difference I see is your create instance method; and it doesn't seem to be any better/different than mine, because the abstractClassName string saves some space, but then you spend more time searching for the class to instantiate with the Class.forName().

[Shephiroth]

Kyle, not sure why should commit to you, if its different. Read 2, 3 and 4 again.

The way you implemented, you must change your code every time, because as you use class you need to know them at compile time. In my implementation, you need string (evaluated in execution time), no need to edit any .java, just the .property file.

Another advantage, what if we want to expand it later and let more implementations than just based on OS.

If you dont like it, say it.

[kylecbrodie]

@Shephiroth haha I was giving constructive criticism. Well two and three seem to be tied together. I get your idea, use strings because they are easier to store; but then if you think about it I could just store Class.getName() and it will be the same. So when you realize that then you can see that they are identical just that I use a class variable and store a string whereas you use a string to get a class variable.

Your second paragraph brings a good point, and I'm adding a way to change the implementation easily and make it expandable though adding more implementations would be done by devs so editing the .java wouldn't be a problem.

If you were concerned about not getting credit for sending a pull to my branch, don't be. I believe strongly in giving credit where credit is due and I would add your name in as co-author. Also in your pull you could just add a comment at the top of the classes you change with your name.

[Maescool]

what is the status of this pull?

[kylecbrodie]

none-existent I suppose. I'm back from my trip so I'm going to work on my rewrite abstraction right now

[Shephiroth]

This pull was never intended to merge, just first approach.

But actually, past days a was thinking about this, and i think its harder than applying an abstract layer. Abstract layer works when data objetcs have a similar action no matter what real object is behind abstract layer. One thing is to separate opengl/lwjgl/dx, all hardware oriented. But this Bitmap system is a lot more complicated. This system is "Render to buffer" instead of "Render to screen", not sure how to say it with words.

Im looking for a way to compatibilize it, im not sure if ill be able to. I hope other coders have more lucky than me.

[kylecbrodie]

Then we should close this pull request and just write about the abstraction on the forum or the issues page (almost like a developer forum right now :P )