what is wrong with this? nothing happens when i use it
-jordan
| Author | Comment | ||
|---|---|---|---|
jmank88 |
extgraph: GraySprite32_OR |
Lead | |
|
GraySprite32_OR(0,0,32,up1,up2,GrayGetPlane(LIGHT_PLANE),GrayGetPlane(DARK_PLANE));
what is wrong with this? nothing happens when i use it -jordan |
|||
Lionel Debroux |
Re: extgraph: GraySprite32_OR | ||
|
Which ExtGraph version are you using ? Which TIGCC version are you using ?
By the way, this board is not the most appropriate one to talk about ExtGraph (it's currently Custom Beta Tests). |
|||
jmank88 |
Re: extgraph: GraySprite32_OR | ||
|
TIGCC-0.95 beta 5
ExtGraph-2.00 beta 1 |
|||
Lionel Debroux |
Re: extgraph: GraySprite32_OR | ||
|
I've seen what is the problem: two movea.l %d3,%a0 and movea.l %d3,%a1 instead of movea.w.
You can work around this by fixing GraySprite32_OR.s and including it in your project (the next beta of ExtGraph won't come too soon). |
|||
jackiechan |
Re: extgraph: GraySprite32_OR | ||
|
I looked at the other GraySprite32_MODE routines and they are all buggies.
We will correct this bug for the next beta. But why don't you use the _R functions (ie GraySprite32_OR_R in your case) ?? |
|||
jmank88 |
_regparm_ | ||
|
whats the advantage of using _R(_regparm)?
-jordan |
|||
Kevin Kofler |
Re: _regparm_ | ||
|
It is more efficient (in both size and speed).
|
|||
jmank88 |
oh | ||
|
i guess that makes sense then
are the old routines just there for backwards comptibility then? |
|||
jackiechan |
Re: oh | ||
|
Yes, you're right
|
|||
Lionel Debroux |
Re: oh | ||
|
Unlike TI and some other programmers, we care about backwards compatibility...
Most brand-new routines do not exist in __stkparm__ mode, we'll never make __stkparm__ versions of them. |
|||
Sebastian Reichelt |
Re: oh | ||
|
This is asked for so often, so I don't understand why you don't turn the non-suffixed versions of the functions into macros that are replaced by the regparm versions.
|
|||
Lionel Debroux |
Re: oh | ||
|
That might break ASM programs using ExtGraph 1.02. There are very few of them, if any.
|
|||
Fisch2 |
Re: oh | ||
|
I think the compatibility issues are going to be mainly with people who have not been programming that long and are not as experienced of programmers. People, if any, who have used ExtGraph in ASM programs are probably going to be more experienced (due to the fact that they program in assembly) and will be able to easily change the names of a few functions.
You will probably get many more questions like the one above than you will by experienced assembly programmers who will have to update the names of their ExtGraph functions. |
|||
jackiechan |
Re: oh | ||
|
> That might break ASM programs using ExtGraph 1.02. There are very few of them, if any.
But ASM programs shouldn't use C header, should they ? |
|||
Sebastian Reichelt |
Re: oh | ||
|
jackiechan: That's the point. Unless they do (which is very uncommon), they will not see the #defines.
|
|||