CoolBasic Party Pack aka yhteisön kasaama partypeli
- Sami The Great
- Advanced Member
- Posts: 485
- Joined: Tue Aug 28, 2007 4:15 pm
- Contact:
Re: CoolBasic Party Pack aka yhteisön kasaama partypeli
CoolBasickin käyttäjä vuodesta 2004.
Re: CoolBasic Party Pack aka yhteisön kasaama partypeli
Coolbasicia ajatellen en usko, että kannattaa lähteä tekemään grafiikasta skaalautuvaa. Jos pelissä pyöritellään objekteja, niin latausajat ovat jo ihan tarpeeksi pitkiä. Skaalaaminen vain pidentäisi latausaikoja (isojen kuvien lataaminen kestää kauemmin ja skaalaaminen vielä kauemmin). Toisaalta jos kaikki piirtokomennot korvattaisiin API:n vastikkeilla, niin tämäkin ominaisuus voidaan lisätä jälkikäteen. Edits: Niin ja jos halutaan objekteja pyörittää, niin pitäisi välillä tallentaa skaalattu kuva, sillä tietääkseni MakeObject+PaintObject yhdistelmällä ei pysty pyörittelemään. Muistaakseni kokeilin joskus ladata pikselin kokoisen objektin ja asettaa sille pyöritysarvon joka tuli sitten PaintObjectin kuvallekin. En muista toimiko se oikein.Sami The Great wrote:Itse ainakin resoluutiota ajatellen tekisin grafiikat skaalautuviksi, jolloin resoluutiolla ei ole väliä.
Tässä vielä versio, missä voi itse kirjoittaa resoluution tai valita natiivin (löytyy tosiaan SCREEN 0, 0, 0, 0; joskin tämän jälkeen pitää vielä kutsua uudelleen SCREEN ScreenW, ScreenH, 0, 0 että toimii). Kysyy halutaanko kokoruutuun, jos sellainen on saatavilla.
Code: Select all
Global RenderW, RenderH, ScreenW, ScreenH, Zoom, MidImage, OffsetX, OffsetY
RenderW = 640
RenderH = 360
Repeat
Text 0, 0, "Kirjoita resoluutio (tyhjä: natiivi)"
Locate 0, 15
ScreenRes$ = Input("leveys X korkeus:")
DrawScreen
Until KeyHit(28)
CloseInput
Cls
ClearKeys
If ScreenRes = "" Then
SCREEN 0, 0, 0, 0
ScreenW = ScreenWidth()
ScreenH = ScreenHeight()
Windowed = False
Else
ScreenW = Int(Trim(GetWord(Lower(ScreenRes), 1, "x")))
ScreenH = Int(Trim(GetWord(Lower(ScreenRes), 2, "x")))
If GFXModeExists(ScreenW, ScreenH, 32) Then
Repeat
Text 0, 0, "Kokoruutu? (Y/N)"
DrawScreen
Key = WaitKey()
If Key = cbKeyY Then Windowed = False : Exit
If Key = cbKeyN Then Windowed = True : Exit
Forever
Else
Windowed = True
EndIf
EndIf
SCREEN ScreenW, ScreenH, 0, Windowed
Zoom = Min(RoundDown(Float(ScreenW) / RenderW), RoundDown(Float(ScreenH) / RenderH))
If ScreenW <> RenderW Or ScreenH <> RenderH Then
MidImage = MakeImage(RenderW, RenderH * Zoom)
OffsetX = (ScreenW - RenderW * Zoom) / 2
OffsetY = (ScreenH - RenderH * Zoom) / 2
EndIf
Floor = MakeObjectFloor()
Grass = LoadImage("Media/Grass.bmp")
PaintObject Floor, Grass
MasterCow = LoadAnimObject("Media/animCow.bmp", 30, 25, 0, 4)
ShowObject MasterCow, OFF
Dim Cow(29)
For i = 0 To 29
Cow(i) = CloneObject(MasterCow)
PositionObject Cow(i), RenderW/2 - Rand(RenderW), RenderH/2 - Rand(RenderH)
tmp = Rand(1) * 2
LoopObject Cow(i), tmp, tmp + 1, 0.05
Next i
TranslateCamera (ScreenW - RenderW) / 2, -(ScreenH - RenderH) / 2
Repeat
TranslateCamera (RightKey() - LeftKey()) * 3, (UpKey() - DownKey()) * 3
DrawGame
Text 0, 0, "FPS: " + FPS()
Text 0, 15, "Zoom: " + Zoom + "x"
Text 0, 30, "Resolution: " + ScreenW + "x" + ScreenH
Text 0, 45, "Render: " + RenderW + "x" + RenderH
DrawToWorld ON
Box -RenderW/2, RenderH/2, RenderW, RenderH, 0
MAIN_DrawScreen()
Forever
Function MAIN_DrawScreen()
If ScreenW <> RenderW Or ScreenH <> RenderH Then
For y = 0 To RenderH - 1
For i = 0 To Zoom
CopyBox 0, y, RenderW, 1, 0, y * Zoom + i, SCREEN(), Image(MidImage)
Next i
Next y
Color 0, 0, 0
DrawToWorld OFF
Box 0, 0, ScreenW, ScreenH
For x = 0 To RenderW - 1
For i = 0 To Zoom
CopyBox x, 0, Zoom, RenderH * Zoom, Int(CameraX()) + x * Zoom + i - ScreenW / 2 + OffsetX, Int(-CameraY()) -ScreenH / 2 + OffsetY, Image(MidImage), SCREEN()
Next i
Next x
EndIf
DrawScreen
End Function
Jäipäs muutama lause huomaamatta aikaisemmin:
Ajattelin että tuo kykyluettelo ja muut tiedot annetaan lisäämällä tyyppikokoelmaan jäsen, jonka arvot sitten sisältävät tietoja. En oikein keksi mitä hyötyä on vaikeustasosta partypelissä, missä pelataan ihmisvastustajia vastaan. Tietenkin ympäristöä voi muokata (lisäillä esteitä tai muuta), mutta muutokset ovat samat kaikille. Yksi mahdollisuus on tietenkin jokaiselle pelaajalle ominainen handicap-arvo, jolla voidaan sekä tasoittaa peliä että luoda vaikeustasot mahdollisille tiimi/yksinpeleille.atomimalli wrote:Tähän mennessä taitaa olla selvää tuo, että pelit edustavat itseään yhdellä funktiolla, joka palauttaa eri parametreilla kaiken tarvittavan. Eheyden vuoksi kannattaa varmaan olla pakollisena toteutettavana joku kykyluettelo, jossa kerrotaan että mitä kutsuja se tukee tai sitten testausparametri. Tykkäisin ensimmäisestä ehkä enempi. Tuohon olisi sitten helppo lisätä toiminnallisuutta ilman että kaikki pelit hajoavat.
Toimintoja olisi ainakin pelin nimen, logon/kuvan, tuetut pelaajamäärät, tuetut vaikeustasot jne. Jos peli ei esimerkiksi tue vaikeustason valintaa, niin api ei välitä vaikeustasopyyntöä pelille.
EDIT2:
Nyt on lista jo jossain vaiheessa, voit lukea sen wikistä: https://github.com/aXu-AP/CoolBasic-Party-Pack/wiki
Atomi kirjoitteli jo mukavat määrät koodia. Huomasin, että koodin kirjoittamiseen tarvitaan säännöt
Tässäpä siis muutamia vinkkejä kaikille, jotka aikovat osallistua projektiin:
- Käytä sisennyksiin sarkainta, ei välilyöntejä (cb:n editorissa on asetus Tab lenght: -- Spaces, ota rasti pois)
- Nimeä kaikki minipelejen käyttöön tarkoitetut funktiot (ja muut globaalit) etuliitteellä API_. Sisäiset funktiot etuliitteellä MAIN_. Näin on selvää, mitkä toiminnot ovat tarkoitettu mihinkin käyttöön. Ylimääräisten etuliitteiden muistaminen aiheuttaa vain päänvaivaa
- Rivinvaihdot windowsin tapaan (tästä ei tarvitse välittää, jos kirjoitat windowsilla)
- Ääkköset menevät pieleen jos ne on tallennettu eri koodauksella kuin mitä cb käyttää (mikähän lienee?)
- Lisää lyhyt kommentti funktion tehtävästä ja mahdollisesti epäselvistä parametreista riviä ennen funktion määrittämistä
Re: CoolBasic Party Pack aka yhteisön kasaama partypeli
Esittelen tässä vaihtoehdot ja muuta tietoa:
800x600 - tuettu ~kaikilla näytöillä kokoruudussa. Ei liian suuri eikä liian pieni. Antiikkista 4:3 kuvasuhdetta. Ohjelmallisesti skaalaten (doublepixel) liian korkea tavallisille näytöille jo kaksinkertaisena.
720x480 - enpä tällaiseen ole ennen törmännyt, mutta tämä on eräänlainen välimalli 800x600 ja 640x360. Kuvasuhde 3:2. Kaksinkertaisena mahtuu useimmille näytöille.
640x480 - toinen perinteinen resoluutio, joskin kaikki näytöt eivät tue näin pientä. Kuvasuhde 4:3. Kaksinkertaisena mahtuu useimmille näytöille, parhaiten soveltuu 1280x1024 resoluutiolle.
640x360 - variaatio edellisestä. Tämä on Full HD-resoluutio jaettuna kolmella, joten skaalautuminen on erittäin hyvä. Kuvasuhde 16:9. Kaksinkertaisena mahtuu useimmille näytöille, HD-näytöille kolminkertaisena. Soveltuu myös hyvin 1280x1024 resoluutiolle.
Ota huomioon yleisimmät näyttöresoluutiot:
1920x1080 (full HD), 1680x1050, 1280x1024, 1366x768 (kannettavat). Nämä resoluutiot muodostavat yli 60% steamin käyttäjien näyttöresoluutioista.
4:3 kuvasuhteelle on yleensäottaen helpompi kehittää 2D-ohjelmia. 16:9 on jo aika kapea ylhäältäpäin kuvatulle pelille. 3:2 on siitä välistä.
Tässä on testiohjelma, jolla voit testata edellä mainittuja resoluutioita eri näyttötiloissa. Paina ohjelman alussa enter niin saat auki näyttösi natiiviresoluution. Välilyönnistä vaihtaa renderöintiresoluutiota.
Code: Select all
Global RenderW, RenderH, ScreenW, ScreenH, Zoom, MidImage, OffsetX, OffsetY
Repeat
Text 0, 0, "Kirjoita resoluutio (tyhjä: natiivi)"
Locate 0, 15
ScreenRes$ = Input("leveys X korkeus: ")
DrawScreen
Until KeyHit(28)
CloseInput
Cls
ClearKeys
If ScreenRes = "" Then
SCREEN 0, 0, 0, 0
ScreenW = ScreenWidth()
ScreenH = ScreenHeight()
Windowed = False
Else
ScreenW = Int(Trim(GetWord(Lower(ScreenRes), 1, "x")))
ScreenH = Int(Trim(GetWord(Lower(ScreenRes), 2, "x")))
If GFXModeExists(ScreenW, ScreenH, 32) Then
Repeat
Text 0, 0, "Kokoruutu? (Y/N)"
DrawScreen
Key = WaitKey()
If Key = cbKeyY Then Windowed = False : Exit
If Key = cbKeyN Then Windowed = True : Exit
Forever
Else
Windowed = True
EndIf
EndIf
SCREEN ScreenW, ScreenH, 0, Windowed
ChangeRes(640, 360)
Floor = MakeObjectFloor()
Grass = LoadImage("Media/Grass.bmp")
PaintObject Floor, Grass
MasterCow = LoadAnimObject("Media/animCow.bmp", 30, 25, 0, 4)
ShowObject MasterCow, OFF
Dim Cow(29)
For i = 0 To 29
Cow(i) = CloneObject(MasterCow)
PositionObject Cow(i), RenderW/2 - Rand(RenderW), RenderH/2 - Rand(RenderH)
tmp = Rand(1) * 2
LoopObject Cow(i), tmp, tmp + 1, 0.05
Next i
TranslateCamera (ScreenW - RenderW) / 2, -(ScreenH - RenderH) / 2
Repeat
If KeyHit(cbKeySpace) Then
CurRes = CurRes + 1
If CurRes > 3 Then CurRes = 0
Select CurRes
Case 0
ChangeRes(640, 360)
Case 1
ChangeRes(640, 480)
Case 2
ChangeRes(720, 480)
Case 3
ChangeRes(800, 600)
EndSelect
EndIf
TranslateCamera (RightKey() - LeftKey()) * 3, (UpKey() - DownKey()) * 3
DrawGame
Text 0, 0, "FPS: " + FPS()
Text 0, 15, "Zoom: " + Zoom + "x"
Text 0, 30, "Resolution: " + ScreenW + "x" + ScreenH
Text 0, 45, "Render: " + RenderW + "x" + RenderH
Text 0, 60, "Press SPACE to change render resolution"
API_DrawScreen()
Forever
Function ChangeRes(w, h)
RenderW = w
RenderH = h
Zoom = Min(RoundDown(Float(ScreenW) / RenderW), RoundDown(Float(ScreenH) / RenderH))
If ScreenW <> RenderW Or ScreenH <> RenderH Then
If MidImage Then DeleteImage MidImage
MidImage = MakeImage(RenderW, RenderH * Zoom)
OffsetX = (ScreenW - RenderW * Zoom) / 2
OffsetY = (ScreenH - RenderH * Zoom) / 2
EndIf
EndFunction
Function API_DrawScreen()
If ScreenW <> RenderW Or ScreenH <> RenderH Then
For y = 0 To RenderH - 1
For i = 0 To Zoom
CopyBox 0, y, RenderW, 1, 0, y * Zoom + i, SCREEN(), Image(MidImage)
Next i
Next y
Color 0, 0, 0
Box 0, 0, ScreenW, ScreenH
DrawToWorld OFF
For x = 0 To RenderW - 1
For i = 0 To Zoom
CopyBox x, 0, Zoom, RenderH * Zoom, Int(CameraX()) + x * Zoom + i - ScreenW / 2 + OffsetX, Int(-CameraY()) -ScreenH / 2 + OffsetY, Image(MidImage), SCREEN()
Next i
Next x
EndIf
DrawScreen
EndFunction
Niin nyt kun tuli mieleen, voiko git repon siirtää huoletta toiseen kansioon ilman että se menee rikki? Minulla on nyt tuo repo vähän hankalassa sijainnissa löytää se aina käsin, en tullut ajatelleeksi niin tarkkaan luodessani sitä :/
Re: CoolBasic Party Pack aka yhteisön kasaama partypeli
Ainiin, ja GitHubista sen verran, että näytette kommentoivan aikas paljon koodin sekaan. Itse koen todella raskaaksi kehityksen seuraamisen, kun pitäisi lukea kommentteja ympäri koodia. Muutokset -> selkeät commit messaget -> selkeät pull requestit.
Re: CoolBasic Party Pack aka yhteisön kasaama partypeli
API_ prefiksiä käytetään silloin, kun funktio tai muu on tarkoitettu minipelien käyttöön. MAIN_ on pelkästään kehysohjelman kehittäjille. Eli rajapinnan kutsut ovat API_jotain, mutta koskettavat lähes aina MAIN_muuttujia. Kieltämättä se näyttää välillä sekavalta, mutta sitten siinä vaiheessa kun tämä muuttuu siksi yhteisöprojektiksi joksi se on tarkoitettu, kenenkään ei tarvitse kysyä mitä funktioita minipelit saa kutsua. Jos keksit selkeämmän systeemin niin kerro. Hyvä kun huomasit nuo väärät etuliitteet, oli jäänyt sinne silloin kun vaihtelin noita nimiä. Tiedostonimet eivät ole vielä lopullisia, ja jos APIsta ei tule hirvittävän laajaa, saattaa se kokonaisuudessaan mennä yhteen tiedostoon.Sly_Jack0 wrote:Forkkasin tänään itsekin tuon repon ja tarkastellessani koodia huomasin hiukan kummallisuuksia. Näyttää siltä, että API_ ja MAIN_ -prefixejä käytetään sekaisin. Ilmeisesti tästä syystä esimerkiksi Input.cb tiedossa määritellään näppäimille vakiot API_-liitteellä ja MAIN_LoadKeys()-funktiossa taas käytetään MAIN_-etuliitteellä varustettuja vakioita (, jotka luonnollisesti ovat kaikki 0). Mielestäni kaikki APIin liittyvät funktiot, typet, vakiot, globaalit ynnä muu roina pitäisi heivata samaan API.cb tiedostoon.
Ainiin, ja GitHubista sen verran, että näytette kommentoivan aikas paljon koodin sekaan. Itse koen todella raskaaksi kehityksen seuraamisen, kun pitäisi lukea kommentteja ympäri koodia. Muutokset -> selkeät commit messaget -> selkeät pull requestit.
Itse ainakin pyrin kommentoimaan ohjelman toimintaa koodissa, ja tekemiäni muutoksia line commenteilla. Näin koodia voi lukea helposti ilman että tarvitsee katsoa netistä selityksiä, mutta jos jotain on muutettu, siitä ei jää jälkiä koodiin (koska myöhemmin muutoksilla ei ole väliä vaan sillä mitä se nyt tekee).
Commit messaget ovat nyt olleet vielä vähän hakusessa, kun jokaisessa commitissa tuntuu muuttuvan kaikki tiedostot kerralla. Nyt kun rakenne alkaa olla kasassa, päivitykset voivat olla erikoistuneempia jolloin järkevämpiä viestejä voi tehdä.
Re: CoolBasic Party Pack aka yhteisön kasaama partypeli
Re: CoolBasic Party Pack aka yhteisön kasaama partypeli
Sanoisin ettei tämä päde siinä vaiheessa kun projektia vasta luodaan. Sitten kun projektin pohja on valmis (eli muutamat ensimmäiset commitit ovat tehty) niin tämä on todella hyvä sääntö. Jos on pakko kirjoittaa committiin paljon tietoa, niin ensin lyhyt ja ytimekäs (max. 70 merkkiä) tiivistys commitista, sitten kaksi rivinvaihtoa ja tarkemmat selitykset sen jälkeen. Git käsittelee ensimmäisen rivin ikään kuin otsikkona ja se näytetään GitHubissakin kyseisellä tavalla. Jos merkkejä on yli 70, katkaistaan otsikko rumasti keskeltä sanaa kolmella pisteellä.Sly_Jack0 wrote:Nyrkkisääntönä, että jos et voi kuvailla muutoksia yhdellä lauseella, se on todennäköisesti liian iso yhdeksi commitiksi.
Kyllä voit siirrellä ihan vapaasti. Vaikka jotain menisi pieleen niin yleensähän ne muutokset ovat myös netissä niin et edes voi menettää mitään koodia. Voit toki testata kopioimalla projektin kansion ensiksi ja sitten tarkistaa että kaikki toimii ja poistaa alkuperäisen kansion.axu wrote:Niin nyt kun tuli mieleen, voiko git repon siirtää huoletta toiseen kansioon ilman että se menee rikki? Minulla on nyt tuo repo vähän hankalassa sijainnissa löytää se aina käsin, en tullut ajatelleeksi niin tarkkaan luodessani sitä :/
NetMatch - se kunnon nettimättö-deathmatch! Avoimella lähdekoodilla varustettu
vesalaakso.com
Re: CoolBasic Party Pack aka yhteisön kasaama partypeli
Re: CoolBasic Party Pack aka yhteisön kasaama partypeli
Tämä johtaisi niin ikään pidempään kehitysaikaan (pitäisi testailla pelit eri kuvasuhteilla) sekä pelin lataamiseen (kuvien venyttely) ja laatuun (smooth2D päällä voi tulla häikkää maskivärien kanssa, smooth2D päällä tulos on huonoa jos ei kertoimella suurenna).duck wrote:jos pelin kannalta on mahdollista, niin pelaajan itse määrittelemä resoluutio, tai joukko valmiita resoluutiovaihtoehtoja.
Yllättävästi 640x480 on noussut kärkeen. Toisaalta se on kyllä muuten parempi kuin 640x360 paitsi 1366x768-läppäreille ja HD-näytöille. Itse en oikein osaa päättää 640x360 ja 720x480 välillä. Tuo full HD-tukeminen on kyllä tärkeää (mikä on outoa koska en itse omista moista näyttöä), mutta kun kuvasuhde muuttuu vähänkin kapeammaksi, on helpompi tehdä ylhäältä kuvattuja pelejä.
Kiitos Vesq, hyvinhän tuo siirtyi. Ei siinä tietenkään koodin menetyksen vaaraa ole, mutta lähinnä mietin pitääkö linkittää uudelleen (hui kuinka suuri työ ;D ). Alan pikkuhiljaa ymmärtämään gitin ideaa paremmin. Tähän mennessä olen ehkä vähän säästellyt committien kanssa, mutta tuo onkin hyvä idea, että committi pitää yhdellä lauseella pystyä selittämään. Laitanpa senkin tuonne wikiin ohjeisiin.
-
- Moderator
- Posts: 1583
- Joined: Mon Aug 27, 2007 11:24 pm
- Location: Otaniemi - Mikkeli -pendelöinti
Re: CoolBasic Party Pack aka yhteisön kasaama partypeli
Re: CoolBasic Party Pack aka yhteisön kasaama partypeli
Kyllä minun seiskakoneeni antaa luoda pienimmillään 126x10 kokoisia ikkunoita? Kokoruudulle meillä on jo valmiina virtuaaliresoluutiosysteemi jonka variaatioita olen kolmesti tähänkin ketjuun postannut. Toimii ilman hirvittävää säätöä tai kummempaa kikkailua. Itse en tykkää venytetyistä kuvista, kun kuvat ovat pieniä tai ne venytetään pieneksi. Sama pätee kokoruudun käyttöä ei-natiiviresoluutiolla, jos pelissä on jotain pikselintarkasti piirrettyä materiaalia. Latausaikahan olisi pidennetty joka ikisessä tapauksessa paitsi sillä resoluutiolla johon kuvat ovat tarkoitettu.koodaaja wrote:640x360 voi siinä mielessä unohtaa samantien, että Win7 ei luo alle 640x480-resoluutioista ikkunaa ainakaan ilman hirvittävää säätöä tai jonkun sortin virtuaaliresoluutiokikkailua. Itse olen 640x480 kannalla yksinkertaisesti koska se on pienin järkevä, ja vähemmän piirtämistä tarkoittaa vähemmän laskenta-aikoja. Toisaalta myös täysin vapaavalintainen resoluutio on näppärä, ei tarvitse kuin kirjoitella oma kuvanlataaja joka skaalaa valmiiksi ja käyttää relatiivisia resoluutioita kaikkeen - latausaika saattaa nousta isompaa resoluutiota käytettäessä, mutta se on käyttäjän oma valinta.
-
- Moderator
- Posts: 227
- Joined: Wed Aug 29, 2007 3:55 pm
Re: CoolBasic Party Pack aka yhteisön kasaama partypeli
Re: CoolBasic Party Pack aka yhteisön kasaama partypeli
Näinhän juuri teemme tällä hetkellä (no se pitää ehkä lukea rivien välistä ). Sen takia olisi hyvä että se resoluutio oli suht. pieni, sillä 800x600 doublepixelöitynä on liian suuri HD-näytöillekin. Tarkemmin sanottuna liian korkea. En jaksa muita ajatuksiani näistä resoluutioista toistaa, ne on kaikki aikaisemmissa viesteissäni. Aiemmin puhuessani skaalatusta näytöstä tarkoitin vapaasti skaalattavaa näyttöä, en kertoimissa määriteltävää. Suhteellisia resoluutioita ynnä muita hienouksiaatomimalli wrote:Perus tuplapikselijuttuhan ei pidennä latausaikaa yhtään, jos sen tekee jälkikäsittelynä kuvalle. Siinä ei vaan saa pehmeää interpolaatiota mukaan. Illegal Accessissa ainakin semmonen käytössä. Löytyy efektillä laajennettuna sorsan lopusta jos kiinnostaa vilkasta. Se perustuu pariin sataan copyboxiin eli hitaus samaa luokkaa kuin pari sataa dottia.
Et voi kyllä sanoa, ettet ole huomannut tuota tekemääni samaan tekniikkaan perustuvaa drawscreen-korviketta (joka hoitaa myös kuvan n-kertaistamisen). Itse asiassa tänään keksinkin tavan saada sitä vielä nopeammaksi. Siinä missä tällä hetkellä renderöintiresoluution tai zoomikertoimen kasvaessa työtä tulee kaksinverroin lisää (esim. 100x100 kuvan suurentaminen 3x tarvitsee 3*(100+100) = 600 CopyBoxia), niin pienellä muutoksella määrä vähentyy huomattavasti (100+100 = 200 CopyBoxia ja 3*3 = 9 DrawImagea). Tuo muokattu menetelmä löytyy githubista (Functional.cb => API_Drawscreen()).
Interpolaatio tuhoaa pixelartin, sitä en kaipaakaan
Projektin etenemisestä: Tänään lisäilin nuo kaikki median lataamiseen liittyvät funktiot niin, että yritetään käyttää etukäteen ladattuja tiedostoja (globaalia mediaa) ja turha media poistetaan automaattisesti aina minipelin päätteeksi. Pikaisella testauksella manuskan esimerkit toimivat moitteetta, kun lisää API_ etuliitteen kaikkiin funktioihin jotka on korvattu.
API_MakeObject() sisältää myös ominaisuuden, jota ei cb:n alkuperäisessä ole. Se pystyy ottamaan vastaan pyöritysarvon (toteutettu lataamalla yhden pikselin kokoinen näkymätön objekti). Tästä on hyötyä, koska hahmografiikat ladataan usein erikseen värittämistä varten ja lisätään objektiin PaintObjectilla.
Tavoite olisi ensi viikon perjantaina saada ensimmäinen versio APIsta ulos, jonka avulla pystyy jo kehittämään minipelejä, vaikkakin lisää helpottavia ominaisuuksia tehdään varmasti myöhemminkin.
Onpas tuo äänestys kallistunut tuohon 800x600:n. Tällä hetkellä se on johdossa, ja pienet resoluutiot vs isot resoluutiot ovat tasoissa pienet johtaa 8-7 (joku kerkes äänestää ).
Re: CoolBasic Party Pack aka yhteisön kasaama partypeli
NetMatch - se kunnon nettimättö-deathmatch! Avoimella lähdekoodilla varustettu
vesalaakso.com
Re: CoolBasic Party Pack aka yhteisön kasaama partypeli
Eli ehdotatko käytännössä 400x300? Se venyttäminenhän on tietenkin vapaaehtoista, jos haluaa pelata pienellä ikkunalla niin siitä vaan. Itse haluan yleensä pelin vievän mahdollisimman suuren osan ruudusta. Sitten alkaa näyttää huonolta kun kuvaa venytetään enemmän kuin kolminkertaiseksi (riippuu tietenkin näytön tarkkuudesta).VesQ wrote:Itse äänestin juuri 800x600 resoluutiota, koska pidän miellyttävämpänä ratkaisuna sitä kuin tuplapikselöinnin käyttöä. Grafiikoiden latauksessa vain Smooth2D poissa päältä ja ResizeImagella kaksinkertaisiksi, sitten on hyvä. 640x480 venytettynä tuplasti molempiin suuntiin on omasta mielestäni liikaa.
Re: CoolBasic Party Pack aka yhteisön kasaama partypeli
Hmm no kaipa se sitten tarkoittaisi tuota 400x300. Jotenkin tuntuu että se olisi kuitenkin turhan pieni tila ehkä taidan vaihtaa resoluutiotoiveeni 640x480, koska siihen saa sitten jo tarpeeksi tavaraa kerralla ruudulle.axu wrote:Eli ehdotatko käytännössä 400x300? Se venyttäminenhän on tietenkin vapaaehtoista, jos haluaa pelata pienellä ikkunalla niin siitä vaan. Itse haluan yleensä pelin vievän mahdollisimman suuren osan ruudusta. Sitten alkaa näyttää huonolta kun kuvaa venytetään enemmän kuin kolminkertaiseksi (riippuu tietenkin näytön tarkkuudesta).VesQ wrote:Itse äänestin juuri 800x600 resoluutiota, koska pidän miellyttävämpänä ratkaisuna sitä kuin tuplapikselöinnin käyttöä. Grafiikoiden latauksessa vain Smooth2D poissa päältä ja ResizeImagella kaksinkertaisiksi, sitten on hyvä. 640x480 venytettynä tuplasti molempiin suuntiin on omasta mielestäni liikaa.
EDIT: Ohhoh näköjään en enää voi vaihtaa ääntäni. Liekö äänestys jo sulkeutunut vai kuuluuko tämä ihan foorumin ominaisuuksiin? Minulla on kuitenkin nyt yksi ääni tuolla 800x600 vaikka sen pitäisi olla 640x480, sen voinee sieltä päässä laskea pois ja lisätä 640x480:een
NetMatch - se kunnon nettimättö-deathmatch! Avoimella lähdekoodilla varustettu
vesalaakso.com
Re: CoolBasic Party Pack aka yhteisön kasaama partypeli
Äänestystä tehdessä pitää valita, voiko käyttäjä jälkikäteen muuttaa mielipidettään. Defaulttina taitaa olla, ettei voi.VesQ wrote:EDIT: Ohhoh näköjään en enää voi vaihtaa ääntäni. Liekö äänestys jo sulkeutunut vai kuuluuko tämä ihan foorumin ominaisuuksiin? Minulla on kuitenkin nyt yksi ääni tuolla 800x600 vaikka sen pitäisi olla 640x480, sen voinee sieltä päässä laskea pois ja lisätä 640x480:een
Re: CoolBasic Party Pack aka yhteisön kasaama partypeli
Kappas, enpä tuota huomannut. Itsekin ihmettelin, että ei voi valita uudelleen. Lisäänpä sinne sen maagisen rastin. Pitänee seuraavalla kerralla lukea tarkemmin kaikki valinnatChaosworm wrote:Äänestystä tehdessä pitää valita, voiko käyttäjä jälkikäteen muuttaa mielipidettään. Defaulttina taitaa olla, ettei voi.
En ole asettanut äänestykselle loppupäivämäärää. Äänestys suljetaan sitten kun ääniä on sen verran, että voidaan vetää johtopäätös tuloksista.
Niin, ja sanotaan jo se tässä vaiheessa, että äänestyksen lopputulos ei välttämättä ole niin yksiselitteinen, ettenkö tekisi eri ratkaisua kuin äänestyksen "voittaja". Esim. 640x360 on vain kuvasuhteen variaatio 640x480:stä. Samaten tuo olemattoman suosion saanut 720x480 on välimalli niille, jotka haluavat 800x600 resoluution, mutta mahduttaa sen kaksinkertaisena useille näytöille. Nuo isommat ja pienemmät katson lähinnä ääripään (800x600 tai 640x480) ääniksi, koska niitä ei niin moni ole äänestänyt, että oikeasti suurempaa saatika sitten pienempää resoluutiota kannattaa harkita.
Näillä näkymin pitää harkita joko 800x600 tai 640x480. Mutta katsotaan sitä päivän parin päästä minkälaiseen äänijakaumaan päästään.
Re: CoolBasic Party Pack aka yhteisön kasaama partypeli
NetMatch - se kunnon nettimättö-deathmatch! Avoimella lähdekoodilla varustettu
vesalaakso.com