Welcome, Guest. Please login or register.


Author Topic: iEP128emu (Read 50824 times)

Offline varrogy

  • User
  • *
  • Posts: 76
Re: iEP128emu
« Reply #30 on: 2012.January.20. 22:12:27 »
Ezek ugyan nem tűnnek rossznak, de nem tudom, milyen órajelű x86 (pl. Pentium III) processzornak felelnek meg :oops:

Én sem tudom a pontos számokat, de ha saccolni kellene akkor talán P3 800-as körül lehet az 1GHz-es proci.

Kikapcsoltam a hangot, plusz próbálkoztam a frekvenciák állítgatásával is, valóban gyorsult a dolog,
 de sajnos még mindíg nagyon lassú pedig most iPad-en (armv7 1.0GHz) nézem.
Nézegettem az SDL-nek a softwares kép kezelőjét is, de azzal nem sokra jutottam, azt a kódot nem igazán látom át  :oops:
Illetve nem tudom, hogy azzal esetleg lehetne-e valamit gyorsítani.
« Last Edit: 2012.January.21. 00:00:25 by varrogy »

Offline varrogy

  • User
  • *
  • Posts: 76
Re: iEP128emu
« Reply #31 on: 2012.January.21. 01:01:56 »
Ezek ugyan nem tűnnek rossznak, de nem tudom, milyen órajelű x86 (pl. Pentium III) processzornak felelnek meg :oops:

IstvanV,
Profilerrel is megnéztem az emu-t hang nélkül és hanggal is mennie kéne, mert nem használ el minden processzoridőt!
Ahogy korábban említetted valóban a hang konverzió viszi el az idő nagyrészét, illetve most láttam, hogy a demo lejátszás is viszi a processzoridőt!
Próbáltam a vmThread-et is futtatni meg simán threaden nélkül is a virtuális gépet de valahogy mintha nem tudná, hogy ki kellene rajzolnia minden képkockát.
Tuti hogy nálam lesz valami gond, csak még nem jöttem rá, hogy mi az. :)
Lehet, hogy a thread lockok zavarják össze képernyő frissítést?
Csatoltam a profilerről képet is. (hang és hang nélküli futtatásról)

Offline IstvanV

  • EP addict
  • *
  • Posts: 4822
Re: iEP128emu
« Reply #32 on: 2012.January.21. 12:24:31 »
Ahogy korábban említetted valóban a hang konverzió viszi el az idő nagyrészét

Ezen lehetne még egyszerűsíteni, a szűrők például törölhetők (egy "DC block" maradhat, nagyobb frekvenciára állítva), és - rossz minőségű, de telefonra talán elfogadható hang árán - az interpolációt is teljesen el lehet hagyni.

Quote
illetve most láttam, hogy a demo lejátszás is viszi a processzoridőt!

Ez valóban így van, de ha a lejátszás bekapcsolása nélkül is, az bug.

Quote
Próbáltam a vmThread-et is futtatni meg simán threaden nélkül is a virtuális gépet de valahogy mintha nem tudná, hogy ki kellene rajzolnia minden képkockát.
Tuti hogy nálam lesz valami gond, csak még nem jöttem rá, hogy mi az. :)

Le lehet még fordítani asztali Linux rendszerre ? Ha igen, akkor megnézhetném, mi a probléma.

Offline varrogy

  • User
  • *
  • Posts: 76
Re: iEP128emu
« Reply #33 on: 2012.January.21. 12:41:20 »
Ezen lehetne még egyszerűsíteni, a szűrők például törölhetők (egy "DC block" maradhat, nagyobb frekvenciára állítva), és - rossz minőségű, de telefonra talán elfogadható hang árán - az interpolációt is teljesen el lehet hagyni.

Ez valóban így van, de ha a lejátszás bekapcsolása nélkül is, az bug.

Le lehet még fordítani asztali Linux rendszerre ? Ha igen, akkor megnézhetném, mi a probléma.


Elvileg tud menni desktopon egyelőre azokat az SDL osztályokat használja amit Te írtál,
főleg az OpenGL-t irogattam át (gldisp.cpp), hogy menjen OpenGL ES-en de az új kód elméletileg sima OpenGL kompatibilis.

Tettem egy fps countert az SDL main loopjába ami stabil 60-at mutat iPad-en a következő esetekben:
- csak az emuláció fut vm-run(2000) (nincs demo futtatás, nincs rajzolás és nincs hang)
- fut az emuláció vm-run(2000) + fut a batman.demo (nincs rajzolás és nincs hang)
- fut az emuláció vm-run(2000) + fut a batman.demo + hang is van de az akadozik (nincs rajzolás)

És akkor kezd el akadozni az dolog, ha bekerül a
checkEvent a képbe a rajzolással együtt!!!

void SDLGLDisplay::draw()
{
    if (checkEvents()) {
        OpenGLDisplay::draw();
        SDL_GL_SwapBuffers();
    }
}

A kódot később összeszedem és kiteszem ide, most eléggé összevissza van még!

Offline varrogy

  • User
  • *
  • Posts: 76
Re: iEP128emu
« Reply #34 on: 2012.January.21. 16:07:29 »
Ezen lehetne még egyszerűsíteni, a szűrők például törölhetők (egy "DC block" maradhat, nagyobb frekvenciára állítva), és - rossz minőségű, de telefonra talán elfogadható hang árán - az interpolációt is teljesen el lehet hagyni.

Ez valóban így van, de ha a lejátszás bekapcsolása nélkül is, az bug.

Le lehet még fordítani asztali Linux rendszerre ? Ha igen, akkor megnézhetném, mi a probléma.



Osszecsomagoltam a kódot, ha valakinek van XCode 4.2-je akkor le tudja próbálni.
iOS simulatorban nincs gond, tökéletesen fut, de valós eszközön (iphone, ipad) nem jó (a hang akad, kép talán jó) és nem tudok rájönni, hogy mi okozhatja.
Ugyanis a framerate nem indokolja, hogy miért akadozik.
Más az architektura, és emiatt a byte oreder is de elvileg ez be van állítva ahol korábban jelezted. (illetve amig nem irtam át elég furcsa képeket adott :) )

(ez egyelőre csak egy tech demo,
- Betölti a batman.demo-t elkezdi játszani,
- Ha végig húzza valaki az újját képernyőn akkor az reset gombot emulál
- Ha megnyomja valaki a képernyőt akkor az gombnyomást (5-ös) emulál
)
« Last Edit: 2012.January.21. 16:53:17 by varrogy »

Offline IstvanV

  • EP addict
  • *
  • Posts: 4822
Re: iEP128emu
« Reply #35 on: 2012.January.21. 19:11:07 »
A main.mm-ben a ciklus, amely SDL eseményre vár és a képernyőt rajzolja, sok CPU időt fogyaszt. Ezen egyszerűen, de nem túl elegánsan várakozás (pl. Ep128Emu::Timer::wait()) beépítésével lehet javítani. Az eredeti FLTK-s megoldásban az emulátor thread jelezte a GUI-nak, ha van rajzolandó képkocka. A videoDisplay->draw() akkor is visszatér, ha éppen nem rajzol semmit, így a frame rate kijelzés nem jól működik, de ez kisebb probléma. Az alábbi kódrészlet mindkét hibát javítja átmenetileg, de ez nem tökéletes megoldás; a várakozás időtartama változhat attól függően, hogy az OS milyen felbontással tud időzíteni:
Code: C++
  1. void SDLGLDisplay::draw()
  2. {
  3.   while (!checkEvents())
  4.     Ep128Emu::Timer::wait(0.005);
  5.   OpenGLDisplay::draw();
  6.   SDL_GL_SwapBuffers();
  7. }
A dp.bufferingMode-ot érdemes 1-re állítani, ha az SDLGLDisplay létrehozásakor is double buffer mód van beállítva.

A hang problémát talán egyszerűen a puffer méret állításával javítani lehet (az audioOutput->setParameters() hívásnál). De mivel a hangkimenet lassítja az emulációt valós idejű sebességre, a nagy puffer rontja az időzítés pontosságát (akadozik a kép, stb.). Az eredeti PortAudio alapú driver ezt úgy oldja meg, hogy az Ep128Emu::Timer()-el időzít, és a sebességet az audio puffer állapotától függően módosítja, hogy a pufferben átlagosan kb. 50% adat legyen.

Offline varrogy

  • User
  • *
  • Posts: 76
Re: iEP128emu
« Reply #36 on: 2012.January.21. 21:11:57 »
(... én meg itt már tûkön ülök szép csöndben, mert ugyan hozzászólni egy mukkot sem tudok, de évek óta iPhone -om van és álmodozom az "ottani" EMU -ról... :-) Még hang nélkül is eszelõs poén volna! (Persze hanggal pláne... :-) )

Milyen iPhoneod van?

Offline varrogy

  • User
  • *
  • Posts: 76
Re: iEP128emu
« Reply #37 on: 2012.January.21. 23:22:08 »
Code: C++
  1. void SDLGLDisplay::draw()
  2. {
  3.   while (!checkEvents())
  4.     Ep128Emu::Timer::wait(0.005);
  5.   OpenGLDisplay::draw();
  6.   SDL_GL_SwapBuffers();
  7. }
A dp.bufferingMode-ot érdemes 1-re állítani, ha az SDLGLDisplay létrehozásakor is double buffer mód van beállítva.

A hang problémát talán egyszerűen a puffer méret állításával javítani lehet (az audioOutput->setParameters() hívásnál). De mivel a hangkimenet lassítja az emulációt valós idejű sebességre, a nagy puffer rontja az időzítés pontosságát (akadozik a kép, stb.). Az eredeti PortAudio alapú driver ezt úgy oldja meg, hogy az Ep128Emu::Timer()-el időzít, és a sebességet az audio puffer állapotától függően módosítja, hogy a pufferben átlagosan kb. 50% adat legyen.


Köszi a tippeket, átírtam a draw() kódot, hogy helyesen jelezze az FPS-t.
Viszont így kiderült, ha kikommentezem a OpenGLDisplay::draw(); sort akkor az iPad-en futtatva 1300-1400 FPS volt a frissítés, azaz ennyiszer volt úgymond kész képernyő.
Ezután engedélyeztem a OpenGLDisplay::draw(); sort és leesett az FPS displaymódtól függően 4-8 FPS-re, kivéve a 0-ás módnál ott 40-50 FPS volt ez az érték.
Elkezdtem keresgélni a rajzolási kódban ahol már mindent kikommenteztem és kiderült, ha csak a GL_VIEWPORT-ot meghívom (csak ezt az egy sort, kvázi látható rajzolás nincs) már akkor leesik az FPS olyan 50-60 közöttre.

A kérdés, hogy szerinted a GL_VIEWPORT, stb.. openGl függvények össze van kötve az OS VSYNCjével (vagy ezt az SDL csinálhatja) és emiatt csökken a sebesség vagy tényleg ilyen lassú ez a függvény?


Offline IstvanV

  • EP addict
  • *
  • Posts: 4822
Re: iEP128emu
« Reply #38 on: 2012.January.22. 00:24:34 »
A kérdés, hogy szerinted a GL_VIEWPORT, stb.. openGl függvények össze van kötve az OS VSYNCjével (vagy ezt az SDL csinálhatja) és emiatt csökken a sebesség vagy tényleg ilyen lassú ez a függvény?

A draw() hívás törlésekor nem működik megfelelően az FPS kijelzés, mert a checkEvents() visszatérési értéke mindig true lesz; a draw() törli a redrawFlag változót, amely jelzi, ha van megjelenítendő képernyő adat.

Double buffer módban az SDL_GL_SwapBuffers() várakozik a VSYNC-re. Ha ennek a hívását nem törölted, akkor lehet, hogy ha nincs semmilyen OpenGL művelet, akkor nincs hatása, de ebben nem vagyok biztos - nálam legalábbis PC-n nem így van.

Offline Ep128

  • EP addict
  • *
  • Posts: 1849
  • Country: hu
    • Honlapom
Re: iEP128emu
« Reply #39 on: 2012.January.22. 12:30:00 »
Milyen iPhoneod van?

4G S
(Ellenben -a mezei 3 G után- ezt már nem Jailbreak -eltem, (nem is szeretném, a béke kedvéért  :oops: ) tehát csak azt tudom rányomni, amit iTunes -ban szereztem. "Oda" kellene (1x majd...) eljuttatnod az EMU -t.  :) )
(Ha hülyeséget kérdezek, bocsi elõre is: De ha István Ep128 Emu -ját próbáljuk életre kelteni Apple kütyükön, akkor miért "iSpeccy" a topic neve? :-) Ez -elsõ sorban- EP emu, nem Speccy.  :) )

Offline IstvanV

  • EP addict
  • *
  • Posts: 4822
Re: iEP128emu
« Reply #40 on: 2012.January.22. 12:46:36 »
(Ha hülyeséget kérdezek, bocsi elõre is: De ha István Ep128 Emu -ját próbáljuk életre kelteni Apple kütyükön, akkor miért "iSpeccy" a topic neve? :-) Ez -elsõ sorban- EP emu, nem Speccy.  :) )

A Spectrum és CPC emuláció beépítése minimális nehézséget jelent, gyakorlatilag egy sort kell átírni ahhoz, hogy másik gép emulátora legyen.

Online Zozosoft

  • Global Moderator
  • EP addict
  • *
  • Posts: 14722
  • Country: hu
    • http://enterprise.iko.hu/
Re: iEP128emu
« Reply #41 on: 2012.January.22. 12:47:58 »
csak azt tudom rányomni, amit iTunes -ban szereztem. "Oda" kellene (1x majd...) eljuttatnod az EMU -t.  :) )
Beengednek oda már más programot futtató programot?
Quote
(Ha hülyeséget kérdezek, bocsi elõre is: De ha István Ep128 Emu -ját próbáljuk életre kelteni Apple kütyükön, akkor miért "iSpeccy" a topic neve? :-) Ez -elsõ sorban- EP emu, nem Speccy.  :) )
Ezen már én is gondolkoztam :-) Mi legyen a neve?

Offline varrogy

  • User
  • *
  • Posts: 76
Re: iEP128emu
« Reply #42 on: 2012.January.22. 16:49:44 »
Beengednek oda már más programot futtató programot?Ezen már én is gondolkoztam :-) Mi legyen a neve?

Elméletileg igen, beengedik, viszont tényleg elég szigorúak a szabályok. Komolyan veszik a dolgot, eleve a regisztrációnak is éves díja van ami szükséges a beadáshoz.
Dobtak már vissza alkalmazást sokminden miatt. (alkalmazás ikonok helytelen mérete miatt, support url hiánya miatt, stb...)
Valószínűleg, csak olyan formában tud majd bemenni, hogy tartalmaznia kell a futtatható programokat. (pl. játék snapshotok)

Viszont a beadástól még messze van a projekt (sajnos).

A neve végülis lehetne iEP128Emu, amíg nincs jobb ötlet.

Offline Ep128

  • EP addict
  • *
  • Posts: 1849
  • Country: hu
    • Honlapom
Re: iEP128emu
« Reply #43 on: 2012.January.22. 16:55:09 »

A neve végülis lehetne iEP128Emu, amíg nincs jobb ötlet.

Akkor valaki modi nevezze át a topic -ot...  ;-)

Online Zozosoft

  • Global Moderator
  • EP addict
  • *
  • Posts: 14722
  • Country: hu
    • http://enterprise.iko.hu/
Re: iEP128emu
« Reply #44 on: 2012.January.22. 19:16:30 »
Akkor valaki modi nevezze át a topic -ot...  ;-)
Így jó lesz?