Redreamer: pågående

av **Redreamer** » 22 december 2014, 23:05

Ok, sitter och pillar lite med koden nästan varje dag nu. Blir mer och mer trögt ju mer det blir, man får liksom så små steg åt gången till slut, vilket kanske är en varning i sig att man börjar koda "fel". Just nu så har det nästan gått mer bak än fram. Min sprite mot bakgrund fungerar inte längre. Gjorde om funktionen så att den mer generellt skulle kunna laddas med Flera X Y koordinater samt vilka tecken som det skulle kontrolleras "krock" mot. Ska fortsätta debug i morgon, om ja hinner, ska tydligen laga ett par formar Janson inför julen, samt ha uppesittarkväll. Ska försöka lägga upp min progress med detta lilla projekt...
https://drive.google.com/file/d/0B0CHvg ... sp=sharing

av **bjonte** » 23 december 2014, 11:39

Ibland är det motigt. Man gör fel hela tiden. Jag löser det genom att testa ny kod noggrant. Jag brukar steppa igenom instruktion för instruktion i emulator för att se att det beter sig som jag hade tänkt. Jag använder TortoiseHg, som bygger på Mercurial, för att spara alla ändringar i källkoden bakåt i tiden. Då kan jag gå tillbaks och se när saker slutade fungera. Det brukar vara en hjälp för att hitta fel som smugit sig in ändå.

av **Redreamer** » 23 december 2014, 13:03

Någon form av revisionshantering har jag inte kommit igång med, kanske blir senare. Bör ta mig lite tid och intressera mig för debugverktyg, men hittills har jag löst det ändå.

av **Redreamer** » 30 december 2014, 09:53

Kodning på djursjukhuset.
Eftersom sambons hund har en utredning om EP anfall så blir det en långdag eller iaf några timmar på ett djusjukhus i mölndal. Tråkigt att vänta så jag plockade ner laptopen i min nya fina Commodoreväska så jag hade något att göra under tiden. Så nu har man suttit i en dryg timma på en pinnstol och kodat. Nästan fått ordning på min gubbe nu. Han fastnar i hörn och kan gå igenom vissa väggar eftersom punkterna som jag kollar mot ligger för brett isär. Men det går iaf framåt =)
https://drive.google.com/file/d/0B0CHvgqdlMvdc1FPZXMxNDAzblU/view?usp=sharing

Kaffe å kaka nu, sedan påt igen

av **bjonte** » 30 december 2014, 10:45

Vad tråkigt att hunden har fått sådana problem men bra att du kan utnyttja tiden till något bra. Känns det som att du återfår kontrollen över koden nu?

av **Redreamer** » 30 december 2014, 13:27

Jo, man får försöka vända på tråkiga saker. =)

Kontroll över koden får jag nog inte i första taget. Den växer som ett ogräs snarare än en vacker blomma om man säger så. Jag har ju så dålig koll på hur jag skall göra vissa saker rent speltekniskt. Egentligen så skulle man ju sätta sig och göra något flödesschema eller liknande men då blir det snabbt så tråkigt och teoretiskt. Iaf när man inte riktigt vet hur man ska lösa något, en sak är ju när/om jag kommer så långt att ja skapar ett program som jag redan ungefär hur grundstommen i programmet skall fungera. Men jag har lärt mig en del bara sedan i sommar tycker jag, så visst, lite mer kontroll har jag nog.
Kan inte vara nog nöjd med min reference guide, ganska mycket kunde jag men flera viktiga pusselbitar fanns det att få, och fler kvar att lära =)

av **bjonte** » 30 december 2014, 16:03

Jag har aldrig gjort ett flödesschema. Gör inte saker som känns tråkiga och onödiga. Strukturen kommer med erfarenhet. Det är viktigare att få något gjort än att det blir perfekt. Det värsta som kan hända är ju att det blir så trist att du slutar.

Fråga gärna om du vill ha tips på lösningar.

av **Ron** » 1 januari 2015, 16:56

Flödesschema?

Det försökte de lära mig i skolan och fy vad tråkigt :-(

Var oftast små korta rutiner i skolan så att alla skulle hänga med ;-)

Innan man ritat färdigt den så var man klar med koden och den var minst lika bra som om man följt det ritade schemat.

Håller med om att ett stort projekt med många inblandade har nytta av av planering.
Jobbar man själv så är kommentarer i källkoden oftast det som ger mest!

Även om man är van att göra spel på andra plattformar än c64 så är det svårt att vara strukturerad när man kodar i assembler.
Som du skriver så växer koden som ogräs och till slut sitter man och letar en hel del av tiden i den.

Att dela upp källkoden i mindre delar så inte allt ligger i huvud källkoden är lämpligt.
Till exempel kan musik och ljudeffekter vara en egen källkod och laddas in där det finns plats.

När jag gjorde spel på PC så hade jag ett helt bibliotek med egna bra rutiner som jag återanvände för att minska ner utvecklingstiden.
Optimerade jag någon rutin så fick den ersätta den gamla i biblioteket till nästa gång jag behövde den.

Har fått förfrågan att lägga ut källkoden till "Brick Buster" för att hjälpa andra igång men jag tvivlar på att någon annan än jag kan ha nytta av den ;-)

Små rutiner kan vara guld värda men blir det för mycket så orkar man inte sätta sig in i den :-(

Skrev en testrutin för att styra paddlar nyligen och en sådan rutin hade jag uppskattat så jag inte hade behövt uppfinna hjulet igen.

av **Redreamer** » 2 januari 2015, 17:07

Ja, skolan lyckas ofta inte engagera en riktigt till att få saker att vara roliga. Gick en turbo pascal kurs under gymnasiet, vet att vi mest skulle sitta och jobba efter boken. Kanske var man ganska okunnig då för att mer använda boken som referens men om man hade sporrats till att skriva ett spel eller något så hade man säkert engagerat sig mer... Fast jag har alltid haft svårt att göra saker på beställning, det är bara på jobbet jag kan koncentrera mig, för där måste jag.

Jaja, åt fanders med flödesschema och sådant. Jag försöker kommentera mycket men det blir ofta ganska självklara kommentarer, men det hjälper nog mer än jag tror. Man kikar ju lite på dem för att se var man är i koden. Hur jag ska dela upp koden i flera stycken vet jag inte... förstår inte riktigt hur man arbetar så.

Jo, har man väl skrivit en rutin så lär man ju använda det som var bra med den i nästa projekt också.

Idag så har det blivit tillagt lite nya saker till min spelmotor eller vad man ska kalla det. Började på en ny snurra för att kunna modifiera saker man stöter emot. kunde modifiera en tidigare funktion och vips var det ganska snabbt gjort. Bara ena hörnet som kan "modifiera" bakgrunden, men det är en början. Har även lagt till en skjuta funktion, glömde X msb biten för den spriten.

https://drive.google.com/file/d/0B0CHvgqdlMvdRkFSNEdzc25tZFE/view?usp=sharing

Har även börjat titta på TurtoiseHG men det fungerade inte riktigt som turtoise vi har på jobbet, så jag får ta och kika på hur man fixar sitt repository (youtube eller någon bra lathund) , det brukar ju vara den knöliga biten.

av **bjonte** » 2 januari 2015, 18:55

Redreamer skrev:Jaja, åt fanders med flödesschema och sådant. Jag försöker kommentera mycket men det blir ofta ganska självklara kommentarer, men det hjälper nog mer än jag tror. Man kikar ju lite på dem för att se var man är i koden. Hur jag ska dela upp koden i flera stycken vet jag inte... förstår inte riktigt hur man arbetar så.

Jag har en main.asm-fil som innehåller basicraden och en enkel loop. I filen inkluderar jag andra asm-filer med kod som jag har delat upp per område. I det enklaste fallet är det bara en fil, till exempel drawbridge.asm som har all kod som rör vindbryggan. I mer komplicerade fall är det flera asm-filer som hör samman. Vissa allokerar zeropageutrymme, vissa variabelutrymme, vissa kod eller data. Hur man delar upp är nog inte det viktigaste. Den strukturen kommer med tiden.

Redreamer skrev:Har även börjat titta på TurtoiseHG men det fungerade inte riktigt som turtoise vi har på jobbet, så jag får ta och kika på hur man fixar sitt repository (youtube eller någon bra lathund) , det brukar ju vara den knöliga biten.

Det är rätt enkelt. Man högerklickar på en katalog och väljer create repository here. Klart. Sedan är det bara att lägga till existerande filer, submitta och börja ändra och submitta.

Du behöver inte sätta upp någon server eller något krångel.

av **Redreamer** » 3 januari 2015, 17:30

Blev inte så mycket gjort idag. Mest haft problem med att en branch inte går att göra så långt som jag vill

Får göra om strukturen...

Försökte göra multipla assemblerfiler i projektet bara för skojs skull. Verkar inte som att filerna kan se varandra. Jag har lagt till dom till mitt projekt å så.
Nu använder jag CBM studio, vilken kanske inte är så använd av er andra men finns det något generellt som man brukar behöva göra för detta?
Tycker jag har testat allt möjligt plus läst igenom den biten av hjälpfilen. Men jag får väl kontakta snubben som gör verktyget annars.

av **bjonte** » 3 januari 2015, 19:47

Jag har inte koll på hur CBM Studio hanterar detta.

Lösningen på en för lång branch är att ersätta den med en motsatt och en JMP (eller krympa koden då).

beq label

blir

bne temp
jmp label
temp:

Vissa assemblatorer har en sådan variant inbyggd i språket så att man slipper skriva det.

av **Redreamer** » 7 januari 2015, 20:33

En sådan dubbelbranching låter fult

Men om jag inte löser det på något annat vis så är det ju en väg.
Efter att jag delade upp programmet i fler delar så fick jag problem med att spritegrafiken hamnade på fel plats i minnet. Det visade sig att det var själva verktyget som inte hängde med när projektet delat upp sig. Har fått en ny betaversion av cbm studio från utvecklaren, så nu fungerar det fint =) Jobbigt när det hänger på verktygen =(
Det var ju egentligen inte nödvändigt att dela upp projektet, fungerade ju med en stor fil, men det blir ju lite snyggare och förhoppningsvis mer lättöverskådligt nu.
Mycket att göra hemma i lägenheten just nu med en evig ombyggnad i köket som aldrig blir klar (eftersom ja suttit med 64'an ist

) Så nu får ja nog allt prioritera lite, så inte sambon mulnar till, hehe. Så det lär bli att låta 64'an vila, suck.
Tog förresten med och visade jobbarkompisarna vad jag presterat på 64'an över julledigheten, de delade inte riktigt min fascination, haha.

av **Redreamer** » 28 januari 2015, 21:18

Varit lite stilla ett tag med kodningen, men har varit hemma ett par dagar från jobbet med en jobbig snuva som förhoppningsvis är borta snart. Jaja, började i går med att skriva om min rutin för "skotthantering" i mitt spel. Så nu fungerar det lite mer som jag tänkt mig. =) Gjorde också om lite så jag inte snubblade på att branshingen blev för lång. Funderar just nu på hur man lämpligast "justerar farten" i ett program. Just nu så har jag ett interrupt som triggar på en viss rasterrad, men om jag vill att min sprite ska röra sig snabbare så antar jag att jag har två alternativ, trigga ett till interrupt någon annanstans eller helt enkelt flytta spriten mer än en pixel åt gången.
Någon som har suttit och funderat på liknande saker och har idéer om detta?

av **bjonte** » 28 januari 2015, 21:52

Det enklaste är nog att flytta fler pixlar i taget. Om det inte går att få i den hastighet som du är nöjd med så kan du alternera mellan att flytta en och två pixlar till exempel. Det blir lite krångligare. Man anger hastigheten som ett heltal och decimaler. Om jag vill ha hastigheten 1.4 pixlar per frame så har du en extra räknare för decimaldelen av positionen.

Kod: Markera allt: walk_right: lda hero_x+1 ; decimaldelen clc adc speed+1 sta hero_x+1 lda hero_x ; heltalsdelen adc speed sta hero_x rts hero_x: .byte 50 ; heltalsdelen .byte 0 ; decimaldelen speed: .byte 1 ; heltalsdelen .byte 102 ; decimaldelen (256*0.4)