Z biblioteką  obsługi VBXE jest jak z OSem - co nas obchodzi jak ona to zrobi? Wywołujesz funkcję i ma działać. Martwimy się jak OS ładuje dane z C:? Nigdy. Kwestia napisania odpowiedniej biblioteki/rozszerzenia OSu.

IMHO taka biblioteka pozwalająca na zarządzenie rdzeniami w VBXE mogłaby być przydatna koderom każdego rodzaju aplikacji do określenia konfiguracji sprzętu. Widziałbym to, jako rozszerzenie OS tak, żeby aplikacje miały dostęp zawsze do aktualnej wersji biblioteki w systemie, a nie do tego z czym aplikacja była skompilowana.

A skoro tak, to deklarowałbym się jako chętny do stworzenia takiego rozszerznia, oczywiście o ile Candle i Electron wyrażą zgodę. Potrzebowałbym jeno konsultacji oraz sugestii ze strony ludzi używających/piszących pod VBXE co mogłoby być w takiej bibliotece potrzebne. Uprzedzam z góry, że do tej pory nic, ale to nic nie napisałem dla VBXE.

> Sam jesteś niezadowolony z możliwości FX-a, a sądzisz, że wszyscy inni będą zadowoleni z rdzenia twojego pomysłu na tyle, żeby nie spróbować zrobić po swojemu czegoś, co potrzebują?

i po to jest ten watek, zeby programista ktory jest niezadowolony z FX przylaczyl sie i podyskutowal co go boli. przypominam: progrmaista ktory chce na taki rdzen pisac programy.

> Co do reszty, sam widzisz, jak to komplikuje życie.

nie, nie jestem za automatycznym przelaczaniem Twojego pomyslu. nie chce sobie komplikowac zycia :-)

Ostatnio edytowany przez xxl (2011-01-06 20:05:26)

wedlug Ciebie jedyny, wedlug mnie koncepcje nowego rdzenia do vbxe uratowac moze tylko grupa programistow (jeden - ja :p juz jest) ktora bedzie pisala programy na vbxe bo tylko wtedy mozna bedzie przekonac electrona do dzialania.

To wystarczy za odpowiedź :)

Myślę, że gier powoli, przynajmniej jeśli chodzi o Rybagsa, będzie przybywać :) Sam Rybags cieszy się, gdy ktoś chwali jego pracę i to go motywuje do dalszej pracy. A samo Spectipede jest dla mnie bardzo grywalne.
Osobiście myślę, że warto pisać gry na to, co już jest, a nie lobbingować Candle'a i Electrona do rdzenia pomysłu xxl'a. Pewnie, zmiany są fajne tyle tylko, że ludzie, poza pasją, mają inne sprawy na głowie. Mi by się nie chciało "ręcznie" wybierać rdzenia.

jeszcze sie zastanowcie nad kwestia "moralna" - na ile atari z 2ma cpu bedzie jeszcze atari - dla mnie przetwarzanie rownolegle na 8bitach to juz przesada
blitter jako wyspecjalizowana jednostka graficzna do operacji na blokach pamieci jest super i myslac poza pudelkiem mozna sporo  nim zdzialac - a ze niektorzy najwidoczniej nie potrafia - coz

blitterem w tej chwili mozna zrobic dowolna gre bazujaca na tilemapie, uzywajac przezroczystosci i antica mozna zrobic paralaxe nie obciazajac dodatkowo blittera
levele sa praktycznie dowolnych rozmiarow jakie moga zmiescic sie w pamieci, a jedynym ograniczeniem jest tu 512k ramu
jakos nie widze zeby ktokolwiek to wykozystal, chociaz tebe moze cos chowac w rekawie

takim cpu mozna tez to zrobic? alez tak! pewnie jakies 5x wolniej...

What I would like for VBXE:

Translate function on Blitter.  Programmer supplies a 256 byte lookup table, and source data is used as index into table which selects each byte to write to destination.
With that we can then perform easy shift/rotate operations, the data is precalculated for us.  A 7 way set of Rotate lookup tables costs us less than 1.5 K

Graphics remapping function.  e.g. for doing C64 conversions, it'd be great to be able to just take 1 or 2 bit per pixel source data and have it automatically remapped to full byte destination per pixel.  Use of existing OR function allows easily giving each sprite it's unique range of colours.

ADD operation on 16-bit data.

Blit operation which loads data into a Palette.  As it is, it's not very practical to do pics with >1024 colours.  If a blit op could do a palette reload, then greatly increased colour range would be a reality.

I'd gladly give up 2 palettes to be able to do that stuff.

> Translate function on Blitter. Programmer supplies a 256 byte lookup table, and source data is used as index into table which selects each byte to write to destination.
With that we can then perform easy shift/rotate operations, the data is precalculated for us. A 7 way set of Rotate lookup tables costs us less than 1.5 K

tab_adr         equ $00

                ldy #$00
_copadr         lda adresy,y
                sta tab_adr,y
                iny
                cpy #...
                bne _copadr

adresy  dta a(_adr1),a(_adr2),a(_adr3),a(_adr4), .....

and

            ldx #$00
            ldy #$00
_1          lda position,y
            sta (tab_adr,x)
            inx
            inx
            iny
            cpy #...
            bne _1

and then

            ldy #$00
_adr1 equ *-1
            lda (pzero),y
            ldy #$00
_adr2 equ *-1
            sta (pzero),y
            ldy #$00
_adr3 equ *-1
            lda (pzero),y
            ldy #$00
_adr4 equ *-1
            sta (pzero),y
...
or sth ???

>Graphics remapping function.  e.g. for doing C64 conversions, it'd be great to be able to just take 1 or 2 bit per pixel source data and have it automatically remapped to full byte destination per pixel.  Use of existing OR function allows easily giving each sprite it's unique range of colours.

> ADD operation on 16-bit data.

> Blit operation which loads data into a Palette.  As it is, it's not very practical to do pics with >1024 colours.  If a blit op could do a palette reload, then greatly increased colour range would be a reality.

maybe for such tasks better solution is vbxe with mini cpu instead blitter?
cpu in vbxe has access to vbxe registers...

---

> jeszcze sie zastanowcie nad kwestia "moralna" - na ile atari z 2ma cpu bedzie jeszcze atari - dla mnie przetwarzanie rownolegle na 8bitach to juz przesada

w latach 70 zeszlego stulecia atari w automatach juz to mialo. dla wielu vbxe w atari jest przesada, wpasowales sie w ogolny trend ;-)

> blitterem w tej chwili mozna zrobic dowolna gre bazujaca na tilemapie

no wlasnie... ale kopiowanie prostokatow to nie wszystko

Ostatnio edytowany przez xxl (2011-01-07 09:49:06)

> o tak, np motorola 68k i z80...

:-) nie prawda, a wlasciwie nie tylko :-)

> w automatach drugi cpu byl zawsze do dzwieku, nigdy do grafiki

nie prawda, nie zawsze do dzwieku, do grafiki rowniez :-)

itd.

po tym jakie bzdury co chwile wypisujesz to smialo mozna ignorowac i te ;-) a poza tym nie nadymaj sie tak bo pekniesz i jeszcze smrodu narobisz. :D

Tebe odstrachaj się.
Rdzenie są kompatybilne od 1.5 (?) roku wiec śmiało bierz się za coś większego.

BartoszP :) - tylko, że jak by to samo było zrobione na płytkach np. Lotharka, to już by nie stanowiło argumentu dla Ciebie, bo wyglądało by normalnie :P Nie szata zdobi Atari :D