Welcome, Guest. Please login or register.


Author Topic: game00 (Read 18670 times)

Online geco

  • EP addict
  • *
  • Posts: 5430
  • Country: hu
  • OS:
  • Linux Linux
  • Browser:
  • Firefox 38.0 Firefox 38.0
    • View Profile
Re: game00
« Reply #180 on: 2015.October.19. 09:05:11 »
Megpróbáltam fekete háttér elé átrajzolni a cuccot, de nem túl nagy sikerrel egyenlőre ...

Azt kell mondjam nem állunk túl jól ...

Olyasmi vmi grafokat kell keresni, amit eleve fekete háttér elé rajzoltak, és nem fekete kontúrral képzelték el ...

Ráadásul nálam a 4 szín közül 1 a fekete (háttér), egy másik egy scanline -onként változó kékes/sárgás/fehéres átmenet, és csak kettőt lehet szabadon felhasználni, ezek meg 3 színt használnak szabadon ...

És akkor pld. ebben a sárkányban (véregér?) a fehér részek egy ilyen változó színátmenet lenne, aminek a tényleges színe attól függne, hogy hol van a képen függőlegesen éppen a sprite ...
Nem kell olyat keresned, tedd fel a GIMP-et, és pár klattyintással le tudod cserélni a színeket. (select by volor, fill with fg color)
A Sprite világos színe helyett használhatod a kékes/sárgás/fehéres átmenetet, szerintem a legtöbb esetben nem lesz feltűnő.

Offline ergoGnomik

  • EP lover
  • *
  • Posts: 836
  • Country: hu
  • Stray cat from Commodore alley
  • OS:
  • Windows NT 6.3 Windows NT 6.3
  • Browser:
  • Firefox 41.0 Firefox 41.0
    • View Profile
Re: game00
« Reply #181 on: 2015.October.19. 12:13:46 »
Upszi ... kéne valaki okos megszakértse a dolgot:

Az ep128emu2 -ben gond nélkül futtatok 368 X 272 pixel méretű LPT -vel rendelkező játékot.

Van arra esély hogy ezt nekem megjelenítik valós monitorok ? Vagy én ezt csak összefantáziáltam valahonnan, ill. az emuból ? :)
Nem szakértés.

A PAL videosorban van 52us látható rész a 64us-os teljes sorból. Ez 81,25%. A plus/4-esen ez 370,5 képpont a 456 lehetségesből, és ebből a tényleges megjelenítő terült 320 pixel széles. Viszont van olyan billentyűparancs amivel ezt le lehet csökkenteni 304-re, hogy biztosan elférjen a korabeli monitorokon a megjelenítendő információ. Szóval én nem bizakodnék abban hogy tetszőleges megjelenítőn minden látszani fog széltében.

Függőlegesen fogalmam sincs, 240 (jó esetben 256) sort el tudok képzeni, mint biztosan látszó területet. De lehet esetleg számolgatni valamit a 4:3-as képarány alapján. Mondjuk az pont 240.

De csatlakoztasd fel a Commodore monitorodra amit egyszer említettél, annál jobb próba szerintem nem kell. Tudom, ezt akartad volna elkerülni.

Offline szipucsu

  • EP addict
  • *
  • Posts: 8068
  • Country: hu
  • OS:
  • Windows 7/Server 2008 R2 Windows 7/Server 2008 R2
  • Browser:
  • Firefox 41.0 Firefox 41.0
    • View Profile
    • Webnyelv.hu - Tanuljunk nyelveket!
Re: game00
« Reply #182 on: 2015.October.19. 18:54:40 »
Igazából talán olyan nagyon-nagyon rosszul nem is mutat
Persze, jó lesz az! Valamilyen figura, és animált is. Nem kell művészi grafikának lennie.
SOUND SOURCE 3,STYLE 16,LEFT 16,RIGHT 64,SYNC 2
SOUND SOURCE 2,STYLE 128,PITCH 25.2,SYNC 2
SOUND PITCH 25,SYNC 2
Videos

Offline Z80System

  • EP addict
  • *
  • Posts: 3926
  • Country: hu
  • OS:
  • Windows 7/Server 2008 R2 Windows 7/Server 2008 R2
  • Browser:
  • Chrome 46.0.2490.80 Chrome 46.0.2490.80
    • View Profile
Re: game00
« Reply #183 on: 2015.November.01. 17:42:19 »
Hmmm ...

Lehet hogy ez mindenkinek triviális rajtam kívül, de eszembe jutott egy lájvszéver dolog ...

Az "esett le" hogy tulajdonképp azon kódok 99% -a, melyek megengedik, megengednék hogy magasabb szintű nyelveken íródjanak,
és a közvetlen assembly optimalizálást nem igénylik ... azok valami futási időben nem változó, adatszerű dolgot írnak le,
adatszerű dolgot generálnak.

Tehát pld. eleddig egy LPT tábla generálást, egy csillagmozgás adattábla generálást, ilyesmiket ugye az SDCC -ben írtam le,
egyrészt azért hogy ne kelljen külső mondjuk C projektet felvenni, abban kimentegetni, a konstansokat duplán felvenni, nyilvántartani,
az egész olyan nehézkes ahhoz képest, mintha egyből a "játékba" írom ...

Aztán most hogy áttértem az assembly -re igyekeztem volna ugye azért az ilyen jellegű feladatokhoz nem elveszíteni a kényelmet és
a fejlesztési sebességet.

Ráadásnak most ráeszméltem, hogy pld. az LPT tábla (amit eddig eszembe nem jutott volna egy EP programnál nem "on the fly",
inicializálási időben generálni) ... az is milyen konstans egy dolog már ... gyakorlatilag az adott program konstansai teljesen leírják,
abból generálható, én még a memóriacímeket sem frissítem benne futási időben (mert lassú, még assembly -ben is), hanem vátogatok 2 előgenerált LPT táblát,
szóval az esetek 99% -ában minden ilyen dolog csupán az adott EP projekt konstansaitól függ, de valójában statikus dolog, fordítási időben leírható ...

És abban a fennmaradó részben ahol nem írható le fordítási időben ... na ott meg máris kell az assembly optimalizáció, ott nem megúszható ...

És csak a lehető legritkább (kockáztatom: a projektjeimnél zéró) esetben van az, hogy az adott kód futhat ugyan inicializálási időben, tehát nem kell
hozzá assembly optimalizálás, viszont nem írható le fordítási időben ... nem állítom hogy ilyen nincs, de nekem nem nagyon lesz ...



Szóval a következőt találtam ki:

Az EP projekt build -em egy komplexebb make "projekt" lett, több egymás után leforduló ÉS fordítási időben le is futó,
akár különböző nyelvi és technológiai megvalósítású komponensek összessége.
Ezek nálam nagyjából most úgy tűnik hogy a brass és a VC++ lesz,
de elvi szempontból tökmindegy, és változhat, bővülhet is.

A dolog úgy néz ki, hogy a programok konstansait pld. egy saját "makrónyelven" írom, melyet én rögtönöztem magamnak.
Attól lett "makrónyelv", hogy konkrétan C makrókkal dolgozom fel ezeket a konstansokat (majd szép lassan bővítem a makrókat, ahogy szükség lesz rá),
van olyan makró ami egy kommentet hoz létre a végső generált fájlokban (csak hogy ott is legyen komment, ne csak ebben az eredeti makró file -ban),
van amelyik ilyen vagy olyan típusú konstansot, satöbbit.

Valamint csináltam egy ilyen pársoros C++ programot, mely magába inklúdolja ezt a makró nyelven írt konstans file -t (rendesen compile time, #include -dal),
nyilván meg vannak írva benne a makrók, meg egyéb C++ progi, mely képes kimenteni a beinklúdolt file -okat a brass és a C++ (vagy ami még csak lesz később)
által inklúdolható formában.
Így akkor nem kell minden hülye nyelvhez és technológiához külön párhuzamosan nyilván tartanom egy adott EP projekt konstansait, közös adatait,
hanem generálódnak egy közös formából,
viszont nem is kellett normális programot írjak ami parszol valami saját formátumból,
vagy nem kell a konstansokhoz általános és bőlére eresztett formákat használjak mint pld. az XML,
valamint ki tudom használni a meglévő nyelvek makró funkcióit.

Persze a GNU világegyetemben ismert mindenféle texttranszformációs kütyükkel meg lehetne ezt oldani biztosan elegánsabban is,
melyben használhatnám a saját formát is, mégsem kéne parszereket hekkeljek, hanem egyszerű szabályokkal kifejezhető lenne ilyesmi átalakítás,
de részint nem ismerek ilyeneket, részint jó érezni, hogy a full C++ technológia ott van az ember háta mögött, és semmi nem tudja megakasztani ... :)

Miután ez a progi lefordult, mindjárt le is fut, és kiköpi magából a C++ és brass fordítók által megértett konstans file -okat.

Aztán a következő lépésben lefordul egy szintén kicsi, egy .cpp -s C++ progi (minden külön projektfile, meg ilyesmi nélkül, csak úgy commandline -ból),
mely inkúdolja előzőben generált konstans file -okat, és így meg lehet írni benne az LPT generáló kis C++ kódot, mely kimenti az LPT -ket egy file -ba.

Bármit változtatok a közös konstans file -okban, az tehát egyből egy módosult generált LPT file -t okozhat.

Aztán ugyanez a csillagok generálásával, majd ugyanez bármivel.

Az EP progi pedig mindent csak tölt és használ, semmit nem generál.

Így gyors is lesz a fejlesztés, kedvenc nyelve(i)men akármilyen kényelmesen írhatom őket,
az EP- n pedig még csak a helyet sem foglalják a generáló kódok, mindent oda töltök be,
ahol az valóban van az EP progi futása alatt.


Namost mindebben nincs semmi különösebb finesz,
azon az egy meglátáson kívül, hogy egy ilyen EP demo/game projektben kb. semmi nem olyan,
hogy inicializálási időben futhat, ezért nem kell mindenképp assembly optimalizálni,
viszont futási időben változtatni kéne a lefutást, és így nem lehet egyszerű adatfájlként betölteni.
« Last Edit: 2015.November.01. 17:47:24 by Z80System »
Z80 System

Offline Z80System

  • EP addict
  • *
  • Posts: 3926
  • Country: hu
  • OS:
  • Windows 7/Server 2008 R2 Windows 7/Server 2008 R2
  • Browser:
  • Chrome 46.0.2490.80 Chrome 46.0.2490.80
    • View Profile
Re: game00
« Reply #184 on: 2015.November.01. 18:07:16 »
Persze az is igaz, hogy valahol elvben ez a háttértárigényt többszörözheti,
egy 4K-8K -s méretű LPT tábla assembly generáló kódjának mérete eltörpül az LPT mérete mellett,

így remek "tömörítő kodek" az assembly LPT generáló kód,

de mivel nem magnóról toljuk, és a háttértár mérete is gyakorlatilag korlátlan,
ezért a fejlesztési sebesség növekedése sztm. simán megéri ezt a háttértárméret növekedést ...

(LPT helyett odaképzelhető bármilyen tábla, adatszerkezet, kóddal generálható akármi ...)
« Last Edit: 2015.November.01. 18:38:54 by Z80System »
Z80 System

Online Zozosoft

  • EP addict
  • *
  • Posts: 13519
  • Country: hu
  • OS:
  • Windows 7/Server 2008 R2 Windows 7/Server 2008 R2
  • Browser:
  • Firefox 41.0 Firefox 41.0
    • View Profile
    • http://enterprise.iko.hu/
Re: game00
« Reply #185 on: 2015.November.01. 18:50:07 »
Nem mondom, hogy végig értem amiről beszélsz :oops: