Page 10 of 14

Posted: Wed 14 Dec, 2005 6:56 pm
by Timendus
That's the spirit ;)
Timendus wrote:
Jim e wrote:I'm gonna try add things personally but could you give me quick rundown on precisely the format.
Just take a look at the template that the website generates when you try to add a routine. If you don't understand it, feel free to ask.
Perhaps I should write a few tutorials, one on using the API in your programs and one on adding routines/internal structure of the API..?

Posted: Wed 14 Dec, 2005 7:41 pm
by kalan_vod
Whatever you think is necessary, but I believe just the read me will do :D.

Posted: Wed 14 Dec, 2005 7:46 pm
by Timendus
You think it's clear enough as it is? I guess it should be, but the community seems to be getting so spoiled with tutorials for every possible subject that people seem to forget how to figure things out for themselves :)

Posted: Wed 14 Dec, 2005 7:50 pm
by kalan_vod
Timendus wrote:You think it's clear enough as it is? I guess it should be, but the community seems to be getting so spoiled with tutorials for every possible subject that people seem to forget how to figure things out for themselves :)
Well for me I have a little java in my background, just the basic really. So what your API does is you just call the routine (method in java) and set in the varibles if needed.

Posted: Wed 14 Dec, 2005 8:19 pm
by Timendus
Yup, very true. But I guess that could be confusing to people who've never worked with macro's and include files much before. And I need a place to write things down like preferred label naming, use of routines that you depend on, etc...

Posted: Wed 14 Dec, 2005 9:38 pm
by dragon__lance
@Timendus: do u think API is a good choice for people that have no asm knoledge(like me) and want to have a asm/basic hybred prgm. For instance, the main prgm is in BASIC, but AI is made in asm so its faster.

Posted: Wed 14 Dec, 2005 10:09 pm
by necro
Or in other words...make it simplier for those who have trouble with registers and all...realy, it would be neat if it could be expanded into a full replacement for basic in the areas basic programmers need it and have a gui for it

Posted: Wed 14 Dec, 2005 11:15 pm
by CoBB
Those who have trouble with registers will not be able to code in assembly, no matter how much help they get. It's like saying you've got 'problems with variables'. There are some things you simply can't avoid learning.

For those who don't get it, the API takes care of the mechanical part of programming by providing a simple invocation interface for various routines, partly romcalls. That's all. It will never encompass individual program logic.

Posted: Thu 15 Dec, 2005 12:16 am
by Timendus
I'm afraid CoBB is right. It's not a new programming language, it's just a (rather large) set of routines that you'll always have handy when you include the API. Of course that's not my marketing speech, but I'm afraid it's true ;)

The implications can be big though, because it also brings some standardization and abstraction in the process, but that's a boring story that you're not going to be interested in I think :)

Anyway, it certainly simplifies things for beginners, it helps advanced users to test and develop software faster, and it is actually pretty useful for people who want to write hybrid programs because all they'd have to do is link the routines they wish to use to some input and output OS vars. I know I wished I had something like this when I was still making hybrid programs, about 5 years ago :P So:
dragon__lance wrote:do u think API is a good choice for people that have no asm knoledge(like me) and want to have a asm/basic hybred prgm. For instance, the main prgm is in BASIC, but AI is made in asm so its faster.
Yes, I think it could be. That depends on what you'd require your AI to do. Most AI's are a heap of complicated calculations and conditions though, and it's going to be a lot tuffer to do that in asm than in Basic.

Edit: Nice, 600th post since the last forum wipe :P

Posted: Thu 15 Dec, 2005 12:50 am
by Jim e
The implications can be big though, because it also brings some standardization and abstraction in the process, but that's a boring story that you're not going to be interested in I think Smile
I really like the idea behind a standard for graphics and such. It could make creating and using graphics easier.

Like sprites would also get width, height, method for drawing(or, xor, and, grey). Tiles would have something similar except only once since we assume that they are all alike. And maps could include dimensions, word size, masked indicator bits, and compression used. Maybe we could come to a consensus on this and try to get others to support it, like early morning.

necro wrote:yay Jim! Realy quick question, can a hook be triggered inside of a asm program...as in can you use xlib real statemnets in a asm prog?
why would you want to? It wouldn't be worth it.

Posted: Thu 15 Dec, 2005 4:05 am
by necro
@jim e: perhaps not for you, but can it none the less? One man's trash is another man's way of survival...

@timendus/cobb: err, sorry, wrong terming...I mean messing around with dozens of lines of code just to devide something, obviously there is a minimuim you must know (at least unless you did take it to the level of simplifying)


<off topic edit> browsing the api has helped my understnading a lot though, I think I'll try picking it up again over break.

Posted: Thu 15 Dec, 2005 8:36 am
by Timendus
necro wrote:@timendus/cobb: err, sorry, wrong terming...I mean messing around with dozens of lines of code just to devide something, obviously there is a minimuim you must know (at least unless you did take it to the level of simplifying)
Well, we're working on that then, aren't we? :)
Jim e wrote:I really like the idea behind a standard for graphics and such. It could make creating and using graphics easier.

Like sprites would also get width, height, method for drawing(or, xor, and, grey). Tiles would have something similar except only once since we assume that they are all alike. And maps could include dimensions, word size, masked indicator bits, and compression used. Maybe we could come to a consensus on this and try to get others to support it, like early morning.
Hey, that's actually a really good idea :P So do you suggest that all the data is put in the sprites, and have only one sprite/mappingroutine that autodetects what it should do? That way designing grapical programs would almost be just a matter of drawing the right tiles in EarlyMorning. It wouldn't be optimized for people who just want a xor routine for example though :)

Posted: Thu 15 Dec, 2005 3:02 pm
by Jim e
Timendus wrote:Hey, that's actually a really good idea :P So do you suggest that all the data is put in the sprites, and have only one sprite/mappingroutine that autodetects what it should do? That way designing grapical programs would almost be just a matter of drawing the right tiles in EarlyMorning. It wouldn't be optimized for people who just want a xor routine for example though :)
Sure if you just want to draw one sprite any old method this would be overkill...but if you actually intend to make something useful and/or pretty this maybe the best way to go. Let me see if I could code something useful.


Also I'm noticing a problem, a routine I uploaded, mul16, isn't very useful in it's format. Since most people don't use constants, requiring to load register for every macro that uses inputs looks like it's gonna cause problems.

Posted: Thu 15 Dec, 2005 3:22 pm
by Timendus
Nice additions Jim :) Thanks for taking the math stuff off my back ;)
Jim e wrote:Also I'm noticing a problem, a routine I uploaded, mul16, isn't very useful in it's format. Since most people don't use constants, requiring to load register for every macro that uses inputs looks like it's gonna cause problems.
Yes, that's something I have no solution for. There are two ways to work around it; one is to use single registers and hl in the macros as much as possible, because you can load any other register in them. That way things like math.mul8(c,e) will work properly, but they can give redundant code. The other way is to have the user #define api_use_math_mul16, and call api_math_mul16 with the proper registers loaded, completely bypassing the macro... :(

Anyone have some good ideas?

Posted: Thu 15 Dec, 2005 4:35 pm
by Jim e
Well beyond asking ben to make a SUPER intelligent way of handleing macros, I think direct calls is the only way to satisfy that. I wrote most of an interrupt routines like mirageos's that can handle several things, i try to post later today, after I fully test it.