News:

Printed Amstrad Addict magazine announced, check it out here!

Main Menu
avatar_mr_lou

Graphics framework idea

Started by mr_lou, 12:26, 11 December 11

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

mr_lou

Ok, this is just an idea I've had for quite some time, and I know it will never happen, but I'm just gonna throw it out there anyway.

We already have stuff like Z88DK and SDCC (if you can get it working). And as far as I understand, both of them allows you to relatively easily create your own methods that does various assembler stuff. And for Z88DK we have CPCRSLIB. Probably there are similar libs for SDCC as well(?)

Me being a J2ME coder would love to have something like a bunch of methods with the same names as the javax.microedition.lcdui.Graphics class for my CPC coding.
It's simple stuff really. Example
drawLine(x,y,width,height);
drawString("Hello", x, y, anchor);
setClip(x,y,width,height);
drawImage(img, x, y, anchor);

Some genius CPC coder should create ultrafast methods like those. The firmware call for drawline is too slow. It should be doable. At least there's some fast plotting going on in N.W.C.'s demo Unique.

In theory, it would make it a lot easier to create a game for a cellphone + the CPC at the same time. Just remember, that on J2ME (and Android) the (0,0) position is in the top left corner - it it should be on the CPC as well, instead of the bottom left corner.

Theoretically, having these methods available would also allow us to port many older cellphone games to the CPC, since older cellphones were dead slow, and therefor shouldn't be a problem getting these games to run on the CPC. Only the graphics needs some conversion.

Doable?

TFM

Ehm... see other C thread  ;)
TFM of FutureSoft
Also visit the CPC and Plus users favorite OS: FutureOS - The Revolution on CPC6128 and 6128Plus

mr_lou

Is any hardcore CPC assembler coder willing to try this project with me?
You'll be doing all the assembler coding, implementing the methods of the Graphics class. I'll be testing it intensively with SDCC coding.

We'll be taking it one method at a time, finding an acceptable solution for each of them. I'm willing to pay for your effort (but you have to be really good at that assembler stuff). Name your price.

TFM

I wished I had the time...

So - just in theory - as an idea... Would you be fine with the Z80 routines pretty much alone and would you do all the implementation in a C library?

A C library is what you want, right? Or do I miss th point?
TFM of FutureSoft
Also visit the CPC and Plus users favorite OS: FutureOS - The Revolution on CPC6128 and 6128Plus

mr_lou

I'd like to be able to, by using SDCC, to code using methods like those in javax.microedition.lcdui.Graphics

drawLine(x, y, x2, y2);
Example: drawLine(0,0,200,100);  // Will draw a line from top right corner of the screen, to position x=200 and y=100.
Notice the reverse in coordinates. (0,0) is not at the bottom right as it is in BASIC.

drawString(str, x, y, anchor);
Example: drawString("Hello", 50,50,0); // Will draw Hello at position 50,50
The anchor is supposed to tell where the coordinates are, e.g. TOP|RIGHT of the string, or e.g. CENTER|LEFT.

Now I don't know what you can do with C. But if it was possible to put all those methods in a class-like thingy (maybe a struct?), so that I could do this:
g.drawString(str, x, y, anchor)
- that would be awesome.
But I know that C isn't object oriented. (Neither is Javascript, but I managed to do it with Javascript nevertheless).

Like that.
I wouldn't need all the methods of javax.microedition.lcdui.Graphics though, but I would need some other stuff like Image loading.

myImage = Image.createImage("source"); // could for the CPC return the pointer to the start address of where in memory the image is loaded.
It should also contain the dimensions of the image.
Then g.drawImage(myImage, x, y, anchor);

But since an image usually contains a ton of sprites, one uses setClip first to tell which part of the image you want to draw
g.setClip(0,0,16,16); // From now on we're only drawing on the 16x16 pixels in the top right corner of the screen.
g.drawImage(myImage,-16,0,anchor); // Since we draw the image outside the screen, it is the 2nd sprite on the sheet that appears in the visible clip.

I'm thinking it could be cool if the library kept its own internal pointer to the next available free memory, and any method that loads data, loads it in the next available place. So Image.createImage("source"); would just return to pointer to the address where it was loaded. (Instead of returning an object, like in J2ME).

I think all of this is possible to do, and that the speed could be quite acceptable even. For optimal performance, all methods must be coded in assembler, and avoid standard firmware calls.
If it can be done, it could be really funny to port a lot of older cellphone games to the CPC.

TFM

I had a very short look at that " javax.microedition.lcdui.Graphics" twice. And the first thing that jumped in my eye was  ... opaque pixel, transparent pixel... Ok, a CPC is a CPC and not a Cray (still slower than todays PC's gfx cards...).

I also don't know about all that struct stuff, Octoate already failed to explain it to me, but I know now at least it's cool to have and important for good coding. But to have struct / oo stuff etc. is SOLE dependent on the Compiler. So you have to check if there is a C compiler that allows the usage of that for the CPC. Guess SDCC can do that...

What doest the str in the expression "g.drawString(str, x, y, anchor)" do? The draw(x,y) I already have made.


What we can do on CPC is stuff like:

- Set graphical origin
- Point Plots, ehm I mean plot Points ;-)
- Draw lines (alsolut and relative)
- Load full-screen pictures
- Load smaller pictures (in square shape)
- Usage of relative file management

Well, yes, and all that for all modes and different screen dimensions (80x25 or 64x32 or what-ever-U-like-for-that-C-proggy).


Do you request other (graphical) features?
TFM of FutureSoft
Also visit the CPC and Plus users favorite OS: FutureOS - The Revolution on CPC6128 and 6128Plus

mr_lou

Quote from: TFM/FS on 22:28, 13 December 11
I had a very short look at that " javax.microedition.lcdui.Graphics" twice. And the first thing that jumped in my eye was  ... opaque pixel, transparent pixel... Ok, a CPC is a CPC and not a Cray (still slower than todays PC's gfx cards...).
Yes of course there will need to be adaptions. For example, setColor(int color) takes an int with the RGB color. On the CPC that would be changed into just taking which PEN number to use. And of course there's no opaque pixels. I realize all that.

Quote from: TFM/FS on 22:28, 13 December 11
I also don't know about all that struct stuff, Octoate already failed to explain it to me, but I know now at least it's cool to have and important for good coding. But to have struct / oo stuff etc. is SOLE dependent on the Compiler. So you have to check if there is a C compiler that allows the usage of that for the CPC. Guess SDCC can do that...
With my limited knowledge, I think structs can contain variables, so in that aspect it is kinda like an object. But I don't know if a struct can also contain small functions.
In Javascript you can make a struct-like thingy. For example, I need to be able to call System.currentTimeMillis() which returns the current internal timer (kinda like the CPC has it TIMER variable). In Javascript that's equal to new Date().getTime(). So I make a variable called System with a function called currentTimeMillis() that simply returns new Date().getTime(). That way I can now call the J2ME-command System.currentTimeMillis().

var System = {
  currentTimeMillis: function(ms) {
   return new Date().getTime();
  }
}


If SDCC allows something similar, that would really be great.

Quote from: TFM/FS on 22:28, 13 December 11
What doest the str in the expression "g.drawString(str, x, y, anchor)" do? The draw(x,y) I already have made.
The str is the string to be drawn. (I give an example right after).
Naturally this method should not just use the firmware font, but instead use sprite-graphics for much faster performance.
Yes you have a draw(toX, toY) method. I want a drawLine(fromX, fromY, toX, toY) method.

Quote from: TFM/FS on 22:28, 13 December 11
What we can do on CPC is stuff like:

- Set graphical origin
- Point Plots, ehm I mean plot Points ;-)
- Draw lines (alsolut and relative)
- Load full-screen pictures
- Load smaller pictures (in square shape)
- Usage of relative file management
About images, I'm thinking this framework should make use its own format. The image data starts by containing the image width and height and then comes the image-data. If you load it directly into e.g. &c000, you wouldn't be able to see the image, because the data loads sequentially, unlike a normal CPC image that jumps &800 steps in memory because of the way the CPC has its memory arranged. Instead you'd just see some colored pixels. E.g. if the image was only 32x32 pixels, and you loaded it at &c000, then you'd see the first 32 pixels, then the next 32 pixels on the same line right next to the first 32 pixels.

Quote from: TFM/FS on 22:28, 13 December 11
Do you request other (graphical) features?
Well, e.g. fillRect(). And the functionality of setClip and such.

One of the bigger problems though, is to clear the whole screen between each draw. That's how it's done with J2ME. Using a setColor(0x000000); fillRect(0,0,screen_width, screen_height); to clear the screen before drawing everything again. That would probably not be ideal on the CPC.

I dunno, maybe it's all a bad idea. I can't figure that out. On the one hand it seems to me that it should all be possible. The next minute I'm thinking maybe not.

TFM

#7
Quote from: mr_lou on 07:50, 14 December 11
Yes you have a draw(toX, toY) method. I want a drawLine(fromX, fromY, toX, toY) method.

Just use move(x,y) and draw(x,y). However a drawX(x,y,x,y) should make no problems, but I see not direct need now.

Quote from: mr_lou on 07:50, 14 December 11
About images, I'm thinking this framework should make use its own format.

Why not using OCP art studio windows format? So it's easy to create windows gfx.


That recfill just draws a filled rectangle, right?


To fill / clear the screen will take 200 scanlines time (2/3 of one frame) when using FIOLIB cls() command. But it will take more that a frame in all other libs. So the cls() is - right as you told - the big problem here.

TFM of FutureSoft
Also visit the CPC and Plus users favorite OS: FutureOS - The Revolution on CPC6128 and 6128Plus

mr_lou

Quote from: TFM/FS on 20:08, 14 December 11
Just use move(x,y) and draw(x,y). However a drawX(x,y,x,y) should make no problems, but I see not direct need now.

You are missing the point. The point would be to be able to code using the same methods I'm using on other platforms, thus making it easier to e.g. develop a game for multiple platforms at the same time.

If only I could get SDCC working, I could start it up myself slowly, and then improve each method later. But as I can't make the simplest example work with SDCC, I'm stuck.

Morn

Quote from: mr_lou on 07:50, 14 December 11
With my limited knowledge, I think structs can contain variables, so in that aspect it is kinda like an object. But I don't know if a struct can also contain small functions.
If SDCC allows something similar, that would really be great.

C has function pointers which you can put in structs to simulate object oriented programming:

http://stackoverflow.com/questions/840501/how-do-function-pointers-in-c-work

mr_lou

Quote from: Morn on 21:04, 14 December 11
C has function pointers which you can put in structs to simulate object oriented programming:

Demoniak told me this too. That means it looks promising.

TFM

Quote from: mr_lou on 20:33, 14 December 11
You are missing the point. The point would be to be able to code using the same methods I'm using on other platforms, thus making it easier to e.g. develop a game for multiple platforms at the same time.

I don't agree, due to different gfx capabilities you will always have to change parts of the program. So it doesn't matter if you have to change one word more. These are minor issues. The big issues are to HAVE that kind of functions.

However: If you want to have it that precisely, then you should IMHO create a document that contains all the needed data and post it here. Explain very precise:

- name
- parameters
- and what it shall do

Please EXACTLY!


If doesn't matter if I can help here or not, you have to create that kind of documentation anyway. So go for it ;-)

Quote from: mr_lou on 20:33, 14 December 11
If only I could get SDCC working, I could start it up myself slowly, and then improve each method later. But as I can't make the simplest example work with SDCC, I'm stuck.

Take your time in the end you will succeed!  :)
TFM of FutureSoft
Also visit the CPC and Plus users favorite OS: FutureOS - The Revolution on CPC6128 and 6128Plus

mr_lou

All methods are explained in the Javadoc for javax.microedition.lcdui.Graphics. It is very detailed and precise.

Octoate

Btw, another possibility to build such an abstraction is to use the "#define" command. With it, it should be possible to define the abstraction to the methods, you need. The good thing about that is, that you don't need a data structure, which is stored in the CPCs memory, because the transistion will be done during compile time.

Btw, a great example for that transition is the C version of the program Microchess, which uses defines to emulate the assembler syntax: http://www.andreadrian.de/schach/microchessw.c.
--

TFM

Quote from: mr_lou on 21:54, 14 December 11
All methods are explained in the Javadoc for javax.microedition.lcdui.Graphics. It is very detailed and precise.

Man this goes round and round in circles. As mentioned before (and you agreed!) there are NO opaqe or transparent pixel on CPC. So you can't use that document!

If you want to have such a framework then you should be at least able to set up a proper document for it. On the one hand you offer money, on the other hand you don't even invest some time to make a document which states what you want.
TFM of FutureSoft
Also visit the CPC and Plus users favorite OS: FutureOS - The Revolution on CPC6128 and 6128Plus

mr_lou

Quote from: TFM/FS on 22:04, 14 December 11
Man this goes round and round in circles. As mentioned before (and you agreed!) there are NO opaqe or transparent pixel on CPC. So you can't use that document!

Well I disagree. I believe anyone who knows the CPC can easily tell which methods will be limited. If you can't, then just leave it.

Octoate

Quote from: TFM/FS on 22:04, 14 December 11
Man this goes round and round in circles. As mentioned before (and you agreed!) there are NO opaqe or transparent pixel on CPC. So you can't use that document!
This document is a proper description of the J2ME graphics framework. It is senseless to pick one point to say that this is impossible to use on the CPC. It depends just on the definition. If you write similar methods for the CPC it is definitivly possible to use those methods in a hardware independant way. To build an abstraction you can e.g. say, that the opaque value is omitted. That shouldn't be a problem for a lot of programs.
Btw, Mr.Lou already wrote:
Quote
Yes of course there will need to be adaptions. For example, setColor(int color) takes an int with the RGB color. On the CPC that would be changed into just taking which PEN number to use. And of course there's no opaque pixels. I realize all that.
That are all points, which can be changed by some clever programming and maybe already during preprocessing with defines.
--

TFM

Quote from: Octoate on 22:36, 14 December 11
This document is a proper description of the J2ME graphics framework. It is senseless to pick one point to say that this is impossible to use on the CPC. It depends just on the definition. If you write similar methods for the CPC it is definitivly possible to use those methods in a hardware independant way. To build an abstraction you can e.g. say, that the opaque value is omitted. That shouldn't be a problem for a lot of programs.
Btw, Mr.Lou already wrote:That are all points, which can be changed by some clever programming and maybe already during preprocessing with defines.

You have read what Mr. Lou did write, but you didn't read what I wrote. You miss the point.

That discussion becomes really fruitless here, I quit.
TFM of FutureSoft
Also visit the CPC and Plus users favorite OS: FutureOS - The Revolution on CPC6128 and 6128Plus

TFM

Quote from: mr_lou on 22:09, 14 December 11
Well I disagree. I believe anyone who knows the CPC can easily tell which methods will be limited. If you can't, then just leave it.

The point is not that "I can't", the point is that you are to lazy to contribute. You are not even able to create a proper request for features. So as you suggest, I leave. Search somebody else.
TFM of FutureSoft
Also visit the CPC and Plus users favorite OS: FutureOS - The Revolution on CPC6128 and 6128Plus

mr_lou

Alright. I'm locking this thread now, because it has spawned into a project named sMIDP2lib for SDCC

Continue here please: http://www.cpcwiki.eu/forum/programming/smidp2lib-for-sdcc

Powered by SMFPacks Menu Editor Mod