[C++] Cos / Sin probleem

[Verwijderd]

Ben sinds kort bezig met het ontwikkelen van een GBA game. Ik ben nu bij het draaien van sprites alleen stuit ik daar op een probleempje: c++ blijft maar zeuren over mijn cos en sin??

code:

// bestanden met de geheugenreferenties
#include <math.h>
#include "gba.h"
#include "screenmodes.h"
#include "sprite.h"
#include "keypad.h"


// Een hoop weggelaten code

// maak een macro voor FIXED getallen (zonder komma)
#define FIXED unsigned long

//maak een macro voor de waarde van PI
#define PI 3.14159

// maak een macro om de radiaal te berekenen
#define RADIAAL(myWaarde) (((float)myWaarde)/(float)180*PI)

// Een hoop weggelaten code

// declareer variabelen om de voorberekende SIN- en COS-waarden op te slaan
// zodat er tijd bespaard wordt bij het draaien van de sprite
FIXED mySinus[360];
FIXED myCosinus[360];

// Een hoop weggelaten code


    // doe een loop om alle 360 voorberekende Sinus en Cosinus waarden op te slaan
    for (myLoop = 0; myLoop < 360; myLoop ++)
    {
        mySinus[myLoop] = (FIXED)(sin(RADIAAL(myLoop)) * 256);
        myCosinus[myLoop] = (FIXED)(cos(RADIAAL(myLoop)) * 256);
    }

Het gaat daarbij om de volgende twee regels:

code:

mySinus[myLoop] = (FIXED)(sin(RADIAAL(myLoop)) * 256);
        myCosinus[myLoop] = (FIXED)(cos(RADIAAL(myLoop)) * 256);

Ik krijg deze foutmelding:

undefined reference to 'cos'
undefined reference to 'sin'


zien jullie een fout in m'n code? zit al een behoorlijk tijdje te staren en de msdn library te bewonderen maar ik kom er echt niet uit.

alvast bedankt

[ Voor 6% gewijzigd door Verwijderd op 20-01-2003 15:35 ]

[whoami]

Wat is 'blijven zeuren'?
compiler errors? zoja, welke?

Check ook: Welkom in P&W -> Quickstart (update 2/10/2002)

[ Voor 40% gewijzigd door whoami op 20-01-2003 15:35 ]

[Soultaker]

Wat is "zeuren"?

[ Voor 43% gewijzigd door Soultaker op 20-01-2003 15:36 . Reden: Wat whoami zegt. ;) ]

[Verwijderd]

Sorry inderdaad beetje onduidelijk; ik krijg de volgende compiler errors

undefined reference to 'cos'
undefined reference to 'sin'

[.oisyn]

De GBA heeft geen floating point unit... ik weet niet in hoeverre dit door gcc geemuleerd wordt, maar het kan best eens zo zijn dat de sin en cos functies niet geimplementeerd zijn.

Ik gebruik zelf overigens de compiler van ARM en die kan het wel

[Soultaker]

Welke compiler, welk platform? Onder Unix-achtige operating systems moet je de math library meelinken. "-lm" meegeven aan de compiler, dus.

[ Voor 11% gewijzigd door Soultaker op 20-01-2003 15:40 ]

[Verwijderd]

.oisyn schreef op 20 January 2003 @ 15:40:
De GBA heeft geen floating point unit... ik weet niet in hoeverre dit door gcc geemuleerd wordt, maar het kan best eens zo zijn dat de sin en cos functies niet geimplementeerd zijn.

Ik gebruik zelf overigens de compiler van ARM en die kan het wel

Is dat een goede compiler? Ik ben namelijk pas kort bezig en vond alleen devkitadv. En zo ja, waar kan ik deze downloaden?

[Ruidasilva]

for (myLoop = 0; myLoop < 360; myLoop ++)

Moet dit niet zijn: for (myLoop = 0; myLoop <= 360; myLoop ++) ivm het na lopen van alle 360 waarden en geen 359.......

[.oisyn]

Die kun je niet downloaden, daar moet je voor betalen
Er stond ooit ergens op een van de gba devsites een linkje naar een trial versie, waar ook gekraakte executables in stonden. Deze is later weggehaald

Maar de opmerking van Soultaker zou het ook wel eens kunnen zijn

[Verwijderd]

nope 0 tot < 360 is van 0 t/m 359. Zijn echt 360 waarden

[Creepy]

Ruidasilva schreef op 20 January 2003 @ 15:44:
[...]

Moet dit niet zijn: for (myLoop = 0; myLoop <= 360; myLoop ++) ivm het na lopen van alle 360 waarden en geen 359.......

Aangezien 0 hetzelfde is als 360, nee.
(360 graden in totaal.. van 0 tot en met 359 zijn er toch echt 360)

Edit: DennisBor was sneller.

[ Voor 6% gewijzigd door Creepy op 20-01-2003 15:46 ]

[.oisyn]

Ruidasilva schreef op 20 januari 2003 @ 15:44:
[...]

Moet dit niet zijn: for (myLoop = 0; myLoop <= 360; myLoop ++) ivm het na lopen van alle 360 waarden en geen 359.......

als je geen verstand hebt van C++ zeg dan niets

[Verwijderd]

ok ga ik dat ff proberen thnx

[Verwijderd]

Bedankt allemaal, het is opgelost dmv de oplossing van soultaker

[Ruidasilva]

.oisyn schreef op 20 januari 2003 @ 15:46:

[...]


als je geen verstand hebt van C++ zeg dan niets

Wie zegt dat ik er geen verstand van hebt, ik zat niet op te letten dat is heel wat anders........ Maargoed

[Verwijderd]

Nog een vraagje; de ARM compiler. Je moet er voor betalen zeg je net. Veel?

[.oisyn]

http://www.arm.com/devtools/tools_pricing?OpenDocument

ARM Developer Suite - $5500

[Verwijderd]

OK, ligt 'iets' boven mijn budget

[Verwijderd]

Als ik het goed begrijp probeer je hier juist een cosinus/sinus conversie te maken met behulp van een lookup-tabel.

Alleen kun je er volgens mij beter voor zorgen dat compile-time de cosinus en sinus waarden al ingevuld kunnen worden in een geinitialiseerde tabel, i.p.v. bereken @ runtime (het scheelt geen geheugenruimte verder). Daarvoor zou je de GBA-compiler er op na moeten kijken of deze ook compile-time macro's ondersteunt voor een sinus/cosinus berekening naar fixed-point. Verder zou ik zowiezo de cosinus/sinus lookuptabel combineren, dat scheelt weer 360 fixed-point entries...

En anders moet je even een gewoon host-applicatietje schrijven die met behulp van fprinf een geinitialiseerde sinus-lookup tabel wegschrijft naar een file, die je dan in je source kan includen.

Wat moet de range/schaal van je "FIXED" type trouwens zijn (ik neem aan iets als "[-1,1>", maar nu is het de range van een "unsigned long"?

offtopic:
Trouwens, een van de "two tribes" misschien?

[ Voor 9% gewijzigd door Verwijderd op 20-01-2003 16:16 ]

[Ericston]

Er is eventueel een gratis evaluatie versie.

[.oisyn]

Verwijderd schreef op 20 januari 2003 @ 16:07:
Als ik het goed begrijp probeer je hier juist een cosinus/sinus conversie te maken met behulp van een lookup-tabel.

Alleen kun je er volgens mij beter voor zorgen dat compile-time de cosinus en sinus waarden al ingevuld kunnen worden in een geinitialiseerde tabel, i.p.v. bereken @ runtime (het scheelt geen geheugenruimte verder).

mwoa, het scheelt wat init-tijd en code, maar echt veel maakt dat niet uit

Verder zou ik zowiezo de cosinus/sinus lookuptabel combineren, dat scheelt weer 360 fixed-point entries...

idd, en maak er gelijk een macht van 2 van ipv 360 graden, zodat je de and-operator kan gebruiken om modulair te rekenen (en ja, de ARM 7TDMI kent ook al geen deel-instructie, dus deze wordt eveneens geemuleerd Het gebruik van de / en de % is dus sterk af te raden)

Wat moet de range/schaal van je "FIXED" type trouwens zijn (ik neem aan iets als "[-1,1>", maar nu is het de range van een "unsigned long"?

aangezien hij vermenigvuldigt met 256 denk ik dat hij 24 bits voor de komma en 8 bits achter de komma gebruikt. De spritematrix van de gameboy verwacht z'n elementen overigens in 8.8 fixed point formaat (shorts dus), dus het lijkt me een prima keuze

[ Voor 19% gewijzigd door .oisyn op 20-01-2003 16:20 ]

[Verwijderd]

Wat een vreselijk ding als je er over nadenkt; die GBA, hij kan ook niets maar toch handig voor onderweg naar school

[Verwijderd]

Is de GBA op de StrongArm gebaseerd dan?
Aangezien de GB en de GBC nog gewoon op een Z80 core zijn gebasseerd, ging ik d'r eigenlijk vanuit dat dit ook wel voor de GBA zou gelden, maar dat is dus niet zo

BTW: Een compile-time lookup tabel scheelt niet alleen wat init code, maar geeft ook een betere precisie...

.oisyn schreef op 20 januari 2003 @ 16:16:
[nohtml]
aangezien hij vermenigvuldigt met 256 denk ik dat hij 24 bits voor de komma en 8 bits achter de komma gebruikt. De spritematrix van de gameboy verwacht z'n elementen overigens in 8.8 fixed point formaat (shorts dus), dus het lijkt me een prima keuze

Nee, lijkt me niet. Een sinus/cosinus heeft een signed bereik, en dus zou de fixed signed short moeten worden. Bovendien wordt er nu dus 360x 16 bits meer ge-alloceerd dan nodig voor de sprite matrix en 23 bits teveel voor de range van de functie (alleen 1.8 heb je nodig om zo ook de waarde "1" te kunnen gebruiken, dus voor een bereik van "[-1,1]" ).

[ Voor 56% gewijzigd door Verwijderd op 20-01-2003 16:31 ]

[.oisyn]

Verwijderd schreef op 20 januari 2003 @ 16:22:
Is de GBA op de StrongArm gebaseerd dan?
Aangezien de GB en de GBC nog gewoon op een Z80 core zijn gebasseerd, ging ik d'r eigenlijk vanuit dat dit ook wel voor de GBA zou gelden, maar dat is dus niet zo

het is een ARM7TDMI. In de gba zit ook nog een Z80 core om de gb en gbc spellen te kunnen spelen

BTW: Een compile-time lookup tabel scheelt niet alleen wat init code, maar geeft ook een betere precisie...

met een precisie van 1/256 waag ik dat te betwijfelen

Nee, lijkt me niet. Een sinus/cosinus heeft een signed bereik, en dus zou de fixed signed short moeten worden.

ik had het over de precisie zelf, niet waarin ie op werd geslagen. Het moet idd een signed waarde zijn

Bovendien wordt er nu dus 360x 16 bits meer ge-alloceerd dan nodig voor de sprite matrix en 23 bits teveel voor de range van de functie (alleen 1.8 heb je nodig om zo ook de waarde "1" te kunnen gebruiken, dus voor een bereik van "[-1,1]" ).

Een transformatiematrix bevat meer dan alleen de resultaten van sinus en cosinus. Om de sprites groter te maken heb je bijvoorbeeld waarden groter dan 1 nodig. Vandaar dat het ook 8.8 fixed point is, en niet 1.15 ofzo

[Verwijderd]

.oisyn schreef op 20 January 2003 @ 17:24:
[nohtml]het is een ARM7TDMI. In de gba zit ook nog een Z80 core om de gb en gbc spellen te kunnen spelen

Kan hij dan ook multicore? Dan zou ik het e.a. aan de z80 uitbesteden als dat mogelijk is, da's pas gaaf! Of zit die mooie Z80 werkeloos te wachten op een GB/GBC module...

met een precisie van 1/256 waag ik dat te betwijfelen

ja dan wel, maar als je een 8.8 resultaat wilt hebben, kun je ook prima een 8.24 vermenigvuldigings tabel gebruiken en na de berekening de rest d'r af strippen...

[.oisyn]

[nohtml]

Verwijderd schreef op 20 January 2003 @ 17:45:
[...]

Kan hij dan ook multicore? Dan zou ik het e.a. aan de z80 uitbesteden als dat mogelijk is, da's pas gaaf! Of zit die mooie Z80 werkeloos te wachten op een GB/GBC module...

kan helaas niet