Kérdés:
Méretezhető egy emulátor videója, hogy többet láthasson a szintről?
user297876
2016-02-09 03:01:33 UTC
view on stackexchange narkive permalink

Nem tudom, lehetséges-e, de van-e mód arra, hogy bármely emulátor videóbeállításait módosítsuk, hogy az elejétől a végéig láthassunk egy szintet (pl. Super Mario Bros)?Mint itt:

Super Mario Bros 1-1 Full level map

Tudom, hogy a felülről készült kép photoshoppolt (gondolom), de képes-e egy emulátor erre, és akkor istudj játszani?

Gondolom, nem, mert a játékokat nem úgy tervezték, hogy így játsszák, ezért gyanítom, hogy vannak olyan tényleges technikai korlátok, amelyek megakadályozzák, hogy ez lehetőség legyen - valójában nem csak ilyen ... kicsinyítés.
Egyetértett azzal, amit @AshleyNunn mondott.Az emulátorokat úgy kell építeni, hogy utánozzák, és ne módosítsák a játék működését.Az emuláció meghatározása alapvetően valamiféle rendszer funkciójának reprodukálása (illesztése vagy akár túllépése).Bár azt kellene mondanom, hogy némi "csalás" és framerátás változtatással, állapotmentés stb.
Ugyanaz vagyok, mint te is az elején, de mégis ... Ha készül egy "álemulátor", és rendelkezik ezzel a lehetőséggel, akkor az egy fantasztikus lesz ..: D
Hol találna olyan monitort / képernyőt, amely elég széles ahhoz, hogy mindent így jelenítsen meg?Ellenkező esetben azt képzelném, hogy a függőleges renderelés túl kicsi ahhoz, hogy akár lássam is.o_O
Nos, nem akartam látni a lyuk szintjét.Csak az emulátor képernyőjét szerettem volna beállítani, de a játékelemeknek (pl. Mario) azonos méretűnek kell lenniük.Ezért az emulátor ablakmérete nem befolyásolhatja a játék felbontását
Zavart vagyok ... Be akarja állítani a dolgok méretét, de nem a felbontásukat?Akárhogy is, nincs olyan emulátor, amiről tudom, hogy jelenleg ezt teszi.
Valószínűbb, hogy fix funkciójú 3D-s játékoknál működik, ahol a karaktertől függetlenül (elképzelhető módon) mozgathatja a kamerát.És a modern shader-alapú 3D-s játékoknál ez nem fog újra működni, mert az emulátor nem fogja tudni, hogyan kell ezt megtenni.
@immibis: jól lehet, ha erre lett volna tervezve.de minden támogatott játéknak egy másik egyedi módon kellett keményen kódolnia a funkciót.
@C-dizzle, a kép 3392px széles, a 4K 3840 széles.Rengeteg elég széles!
@user297876 Kérdése és [megjegyzése] (http://gaming.stackexchange.com/questions/254767#comment353769_254772) alapján úgy tűnik, hogy félreérti az emulátor tevékenységét.Ez a program (azaz játék) határozza meg, hogy mi jelenik meg a képernyőn, a konzol vagy az emulátor csak biztosítja az erőforrásokat a program számára, hogy tegye a dolgát.A leírtak megfelelő elvégzéséhez meg kellene változtatni a programot és a programot egy új rendszerbe kell átvinni.Most ez a helyzet az általános játékfejlesztés esetében.A régebbi konzolok sok sarkot vágnak, így a 2D jellegére és a videópufferekre * támaszkodva lehetségesek a trükkök.
Tudom, mit csinál egy emulátor. Nem azért tettem fel ezt a kérdést, mert nem ismerem az emulátor képességeit, de csak arra gondoltam, hogy lehetséges-e. Egy dolgot nem ismerek, hogy hogyan készülnek a NES játékok.A kérdésemre adott válaszok (nézzünk szúrósabban) új távlatot kínáltak számomra, hogy a fejlesztők hogyan használnak különféle trükköket és áldozatokat annak érdekében, hogy a lehető legkisebb teljesítményt érjék el a "kicsi" cpu / video / audio komponenseikből. Mielőtt feltettem volna ezt a kérdést, azt gondoltam, hogy a NES játékokat szokásos módon készítették (például egy általános játékmotort a patronokhoz).
Hat válaszokat:
Rob Watts
2016-02-09 03:15:19 UTC
view on stackexchange narkive permalink

Rövid válasz: Nem

A régebbi rendszereknél (mind a videojátékokhoz, mind az otthoni számítógépekhez) egyet kell szem előtt tartani, hogy a memória korábban luxus volt. Nem volt gigabájtjuk (vagy akár megabájtjuk) sem a tárhely, sem a RAM-on. Ha egy egész szintet csak egy kis részen jelenítenének meg, az értékes számítási erőforrások hatalmas pazarlása lett volna.

Emellett nincs ok feltételezni, hogy minden egyes NES játék kódolt lenne térképét ugyanúgy. Nagyon valószínű, hogy idővel jobb módszereket találtak ki rá, így a hasonló játékokban (SMB1 vs SMB3) is másképp tárolódnak a térképek a memóriában. Ez azt jelenti, hogy nincs ok arra számítani, hogy egy emulátor tudja, hogyan kell egy adott játékot elkészíteni és a teljes térképet az aktuális szintre renderelni.

Sok más probléma is van ezzel - tudom, hogy SMB1, a képernyőn kívüli ellenségek nem mozognak. Arra számítana, hogy egész idő alatt mozognak, vagy csak akkor, amikor a képernyő aktív része eléri őket? Az előbbi befolyásolja a különböző játékok játékmenetét, míg az utóbbi további logikát igényel, amely jelenleg nem létezik a játékkódban.

Még ha módosította is a játék kódját, az emulátor nem lesz képes kezelni, hacsak nem módosítja az emulátort is. Az emulátornak képesnek kell lennie a különböző méretű játéktérképek kezelésére, valamint arra kell számítania, hogy a játék több erőforrást kapjon.

Köszönjük a választ. Igazad van, ahhoz, hogy egy emulátor képes legyen ilyenfajta "kicsinyítésre", tudnia kell, hogyan írták a játékot. Ezért emulátort kell építeni, hogy minden játék képes legyen erre, és ez időpazarlás.
Természetesen nem ez változott - a modern játékok sem tárolják egész világukat egyszerre a memóriában, még kevésbé renderelik.Mindig találunk jobb dolgokat az extra memóriával és a CPU-val, mintsem pazarolni olyan dolgok rajzolására, amelyek amúgy sem láthatók: D
"az SMB1-ben a képernyőn kívüli ellenségek nem mozognak" - Pontosabb lenne azt mondani, hogy az ellenségek egyáltalán nem léteznek, amíg a képernyőn nem jelennek meg.
@duskwuff: Hamis.Bowser lélegzik.(Még ha a sprite nem is létezik technikai szinten, a sztorielmélet szerint egyértelműen ott van ezen a ponton.) És azt mondanám, hogy a Piranha Növények léteznek, mielőtt azok láthatóak lennének.Hmm ... lássuk, sikerül-e valakivel gyorsan előállnom.Gyanítom, hogy Lukitu is (röviden).Ha oszloponként téglák jönnek létre, akkor a cső fölötti úszóterület (eredeti kiadás) a következő oszlop létrehozásáig nem válik potenciálisan halálossá a Super Mario számára.
Ez sem helyes.Alkonyatnak igaza van abban, hogy az ellenségek addig nem léteznek, amíg elég közel vannak a kamerához és ívik a világba.Történetileg igen, Bowser tüzet lő rád, és azok a Priana rejtőzködnek a csövekben, de memória szempontból: Azok a Priana léteznek a csövek tetején, és az "animáció" csak az, hogy eltűnik a hitboxjuk, miközben eltűnneksejt.Hasonlóképpen, Bowser várszintű tüze automatikusan keletkezik, amíg Bowser meg nem ívik, ebben az esetben a sprite-jét használja referenciaként.
Megjegyzendő, hogy egy SMB1 szintnek a Super Mario Makerbe történő átvitele hamarabb teszi az ellenséget, mert az SMM szélesebb képernyővel rendelkezik.
Damian Yerrick
2016-02-09 05:45:13 UTC
view on stackexchange narkive permalink

Ennek kétféle módja van: egy általános és egy játék-specifikus.

A görgetési varrat megtekintése

A Nintendo Entertainment System 2 KiB videomemóriával rendelkezik a vezérlőben Fedélzet. Ez elég a térkép 256x480 vagy 512x240 képpontjához, a Game Pak által választott névadható tükrözési módtól függően. Mivel a Game Pak memóriája olyan kicsi, például 40 KiB a Super Mario Bros. hez, a játékok a térképet tömörítve tárolják, és fokozatosan kicsomagolják videomemóriává, amint a kamera egy szinten halad.

Nova the Squirrel

Mókus Nova © 2018 Joshua Hoffman
Az újonnan feltárt területek görgetési szintű animációja a " PPU görgetés" -től a NESdev Wikiben. A videomemória a tetején van; a renderelt háttér alul van. A narancssárga zárójel mutatja az aktuális görgetési pozíciót. A $ 2000 és a $ 2400 a hexadecimális alapcímek a két térképről a videomemóriában.

Egy speciálisan módosított emulátor figyelheti az írásokat a görgető nyilvántartásba, és naplózza a térkép újonnan feltárt területeit. Egy ilyen jellemző csak a meglátogatott területeket és valószínűleg az ellenség kiindulási helyzetének közelítését mutatja az újonnan meglátogatott területen áthaladó sprite alapján. Ez egyáltalán nem jelenítené meg a nem meglátogatott területeket, ugyanúgy, mint egy PC valós idejű stratégiai játékban szereplő térkép kihagyja a feltáratlan területeket. De ha egy játék térképe nem véletlenszerű, akkor az emulátor gyorsítótárba helyezheti a térképet egy előző, azonos szintű lejátszásból, és felfedheti, hogy mi következik.

Fordított tervezés

Bár a különféle játékok különböző térképadat-formátumokat használnak, több játékot kellően részletesen megterveztek, hogy lehetővé tegyék egy teljes térképet dekódoló PC-program írását. Az ilyen fordított mérnöki eredmények gyakran felkerülnek a RomHacking.net oldalra. Néhány játékot olyan részletesen megértenek, hogy az emberek szint szerkesztőket hoztak létre, például sok játékot a Mario , Zelda , Metroid és Mega Man sorozat.

+1, mert szeretem a technikai hivatkozásokat.Köszönöm szépen.
Mellékjegyzet: Az animáció dollárjelei hexadecimális memóriacímeket jeleznek, nem pedig dollárokat.
Tehát a kérdés megválaszolásához: "Lehetséges-e méretezni az emulátor videóit, hogy többet láthassunk a szintről?"mit mondasz?Melyik emulátort tudja használni az OP?
@Octopus Azt mondom, hogy emulátort lehet létrehozni ezzel a funkcióval, nem pedig azt, hogy bármelyik emulátor ezzel a funkcióval elérhető lenne a nyilvánosság számára.
Ezt alkalmazták, hogy 8 játékos időalapú, szekvenciálisan játszhasson NES játékokat 360 ° -os képernyőn: lásd [cikk] (http://arstechnica.co.uk/gadgets/2015/12/8-players-8-projectors-8-bit-és-csak-egy-nintendo-szórakoztató-rendszer /) és [papír] (https://cgl.ethz.ch/publications/papers/paperZun15c.php)
https://arstechnica.com/gaming/2018/08/widenes-emulation-expands-nes-scenes-past-the-usual-sd-screen-borders/ most látta ezt a cikket - valaki a gyorsítótár-alapú megközelítésen dolgozikemlítetted.
TOOGAM
2016-02-09 05:59:07 UTC
view on stackexchange narkive permalink

Igen, a kért cél egészen biztosan megvalósítható. Ez az állítás nem csak vak elmélet: Valami nagyon hasonló már megtörtént.

Először is elismerem a mások által említett nehézséget. Mivel a szintadatokat valószínűleg különböző módon tárolják a különböző játékoknál (pl. vita a Zelda térképadatairól ), egy emulátornak egyedi adatokra lenne szüksége minden játékhoz. A bővítmények bővülő gyűjteményével ez megtehető. Tehát ellentétes következtetésre jutok. Meg lehet csinálni a kereskedelemben megjelent véges mennyiségű játékért, éppúgy, mint az MMC-k hozzáadása. Ez azonban meglehetősen időigényes projekt lenne, néhány lényeges nehézség miatt.

Többféle játék is létezik szintű szerkesztőkkel. Az ilyen szerkesztők tudják, hogyan kell kiolvasni az adatokat a patronokból, és egy ilyen szoftver hasznos volt azoknak a rajongóknak, akik arra törekedtek, hogy olyan térképeket szerezzenek, amelyek meggyőződésük szerint teljesen pontosak voltak.

Vizsgáljunk meg azonban egy másik megközelítést, amely reagál a hogy valójában mit akartak kérdezni. Egy másik lehetőség a grafika rögzítése a megjelenítéskor. Nem kapja meg a lehetőséget arra, hogy "ezt", (készítse el a térképet), "majd" (a megadott sorrendben, az első lépés elvégzése után) "továbbra is játszhasson", ahogyan a feltett kérdés. Tehát ez nem mutatja meg a teljes térképet azonnal, az első "lejátszás" előtt.

Amit kap, az egy meglehetősen automatizált módszer a korábban a képernyőn látható, meglehetősen automatikusan összerakott térképadatok megtekintésére, amelyek térképeket hozhatnak létre. (Még akkor is, ha változtatásokra lenne szükség, az ilyen térképek kiindulási pontként egy ideig sokkal könnyebbek lehetnek, mint a semmiből próbálkozni.) Mivel a legtöbb NES játék olyan térképadatokat használ, amelyeket egy későbbi "végigjátszás" során megismételnek (véletlenszerűek helyett). térképadatok), az ilyen térképeket meg lehetne nézni, mielőtt újra lejátszanánk. Kérdezõ hozzászólása alapján , a cél nem feltétlenül az egész térkép azonnali megjelenítése.

Ez a tényleges cél alapján ez mindenképpen elérhető (legalábbis korlátozott sikerrel) cél. Egy videó valami nagyon hasonlót mutat, ami valóban megtörtént, a következők használatával:

  • valódi NES
  • valódi NES vezérlők
  • egyedi hardver, amely kombinálta több NES vezérlő bemenete
  • hardver, amely feldolgozta a megjelenített videót

Bár a térképi adatokat nem tárolták hosszú távú használatra, mert ennek a projektnek némileg eltérõek voltak célok, az eredmény térképi adatokat mutatott, miután felhasználta őket. Arra számítok, hogy a technikát meglehetősen egyszerűen módosítani lehet a térképadatok mentése helyett, a térképadatok elvetése helyett. Valójában kiadtak néhány résztérképet (amelyeket egy PDF fájl tartalmaz, és amelyek egy részét a projekt Ars Technical kiadványa említi). Emlékszem, hogy legalább a következő játékokat láttam egy videóban, amely bemutatja ezt a rendszert:

  • Super Mario Bros. (1)
  • Super Mario Bros. 2 (amerikai kiadás) (más néven "Super Mario USA")
  • Super Mario Bros. 3
  • Probotector (a "Contra" újbőrű változata, Európában megjelent)
  • Castlevania
  • Életerő
  • ExciteBike

Ezt a fantasztikus videó mutatja: A 8 bites korszak kibontása (8 bit, 8 játékos , 8 projektor és egy Nintendo Entertainment System) . Készüljön fel arra, hogy leesik az állkapcsa a puszta félelmesség miatt. További részleteket a YouTube videó megjegyzésében hivatkozott és itt hivatkozott weboldal nyújt: Ars Technica cikk: 8 bit, 8 lejátszó, 8 projektor és egy Nintendo Entertainment System .

A PDF fájlból (terjesztő: A 8 bites korszak kibontása ): "Mivel célunk a 360 fokos vetítés volt, az oldalsó görgetéses játékokra összpontosítottunk, és kifejlesztettünk egy követési algoritmust, amelyet e felhasználási esetre terveztünk. A módszerünk jelenleg nem támogatja a függőleges görgetést vagy a bonyolultabb kamera mozgását." (Gondolom, az embereknek kevésbé lett volna érdekes tapasztalatuk, ha elég messzire jutnak a Life Force-ban.)

Köszönjük a visszajelzést ! Ez a vita egy egyszerű kérdésből egy kicsit jobban elgondolkodtat azon, hogy miként készülnek a játékok, főleg a patronokon.Örülnék, ha ezzel kapcsolatban lennék a számítástechnikai karon.:)
Ajánlom az Atari korai történetének "Racing the Beam" -jét az MIT "platform studies" csoportjából.https://mitpress.mit.edu/books/racing-beam
Probst
2016-02-09 21:31:32 UTC
view on stackexchange narkive permalink

Igen, mivel nem adott meg emulátort, a Dolphin GC / Wii emulátor képes kibővíteni a nézetet az eredetinél nagyobbra, 3 monitorom van, és több játékot is játszottam a Dolphin-ban 5760x1080-as felbontással.Ennek ellenére sok furcsa probléma merülhet fel, gyakran a fejlesztők és a művészek lustálkodnak olyan dolgokkal kapcsolatban, amelyek állítólag nem szerepelnek a képernyőn, és a külső széleken lévő dolgok eltorzulnak, furcsán viselkednek vagy egyszerűen nemott.Ezek a problémák még a népszerű PC-s játékokban is némileg gyakoriak.

NEM nevezném "lustának", hogy ne aggódjak azon dolgok megfelelő kezelése miatt, amelyeket a tervezésük szerint nem fognak használni.Olyan, mintha egy autómérnököt "lustának" neveznénk, amiért nem Chevy Cobalt-ot terveztek interdimenzionális utazásra.
Nos, az emulált játékokon talán nem azért, mert konkrét hardver- és kimeneti felbontásokra szánják őket, mégis a PC-s játékokon.Mint például a League of Legends, ha felteszem 3-ra, akkor a térképet körülvevő háttér nem elég nagy, és minden csak fekete marad.A játék modifikációk nélkül támogatja az 5760x1080-at, így tudják, hogy az emberek meg fogják csinálni, és csak megnövelhették volna a háttérképet, de lusták voltak hozzá.
A LoL-ben aggódhatnak a több monitor használata során alkalmazott tisztességtelen előnyök miatt is.
A Wii-hez hasonló konzolokat úgy tervezték, hogy egyetlen kijelzőhöz csatlakoztathassák őket, meghatározott maximális felbontással.A játékfejlesztőnek nem kell megterveznie a motort, hogy jól meghatározott tartalmat jelenítsen meg a Wii 854x480-as nézetablakán kívül.Lehet, hogy több adat van a nézetablakon kívül a képkockabemutatóban, de nem szabad arra számítania, hogy jól definiált.
"az emulált játékokon nem azért, mert konkrét hardver- és kimeneti felbontásokra szánják őket, hanem a PC-s játékokra", szó szerint csak ezt mondtam, de mindenképpen köszönöm ...
bwDraco
2016-02-12 12:08:42 UTC
view on stackexchange narkive permalink

Ez a NES élő emulációja alatt nem lehetséges.

  • Az Ön által leírtaknak megkövetelniük kell, hogy a grafikus motor a nézetablakon (a látható képernyőterület). Míg a modern 3D-s motorok a nézetablakon kívüli tartalmat renderelik a framebufferbe (ami lehetővé tenné a nézetablak kibővítését az extra tartalom megjelenítéséhez), ezt nem szükséges megtenni a Super Mario Bros. típus, és ez sem lenne jó módszer a NES korlátozott hardvererőforrásainak felhasználására.

  • Valójában a videó a NES-en található hardveren a grafikus memória mai értelmében még nincs képkockája sem, amely renderelt videokereteket tárol a képernyőn. A csempéket és az írásokat a memóriában tárolja, és közvetlenül a képernyőn jeleníti meg, így az általad leírt technikailag nem lehetséges a NES-en. (Különböző chipek bővíthették a grafikus hardver képességeit, de ezek egyike sem teszi lehetővé, hogy a konzol framebufferré rendereljen, nem is beszélve arról, hogy elegendő memóriát biztosítana az egyik számára.)

Daniel
2020-06-01 03:25:27 UTC
view on stackexchange narkive permalink

Igen. Biztosan. Az összes NES (és hasonló) játék, amelyek görgetést végeznek, minden megjeleníthető lapkájának minden helyzetével rendelkezik, valahogyan regisztrálva a ROM memóriachipben. Ezeket az információkat a NES eredeti programja csak akkor olvassa el, amikor a jelenet látható, mivel az adott korszak rendszereinek nem volt számítási erőforrása pazarlás céljából. De még akkor is, ha a jelenet még nem él a RAM memória chipen futó képernyőn, valahogy mégis létezik a jelenet a statikus ROM memória chipen. Az emulátor szokásos célja az, hogy az eredeti programot a lehető legeredetibb módon futtassa, nagyon kevés szándékkal, hogy a dolgokat valahogy kibővítse. Ez azonban nem igaz a grafikus kijelzőre. Az emulátorok szándékukban áll valamilyen grafikus bővítést végrehajtani. Egy ügyes programozó, akinek akarata a látómező grafikus kibővítése a NES emulátoron, elméletileg elolvassa a teljes térképet a ROM-on, és az emulált képernyőt a teljes térkép tetejére helyezheti, minden képkocka megfelelő helyén, és a monitoron egy az egyéni ablak elvágja ezt a teljes térképet úgy, hogy a tényleges emulált eredeti képernyő elfoglalja a megjelenített testreszabott vágás kisebb részét. Ebben az esetben azonban az objektumok szinte soha nem mozdulnak el, ha kívül esnek az eredeti látómezőből. Kivéve, ha egy másik ügyes programozó úgy dönt, hogy olyan mesterséges intelligencia hálózatot programoz, amely gépileg megtanulhatja a cserépcsere viselkedését, tekintettel a karaktermozgásokra és a játékidőre. Ha igen, akkor sok objektum akkor is elmozdul, ha nincsenek az eredeti képernyőn, mindaddig, amíg a mesterséges ideghálózat elég okos ahhoz, hogy egy logikát adjon ki annak a mozgásnak, amely az objektumot a pontos helyre helyezi, amikor belép az eredeti képernyőre. A probléma az, hogy eddig még senki nem csinálta ezeket a dolgokat.



Ezt a kérdést és választ automatikusan lefordították angol nyelvről.Az eredeti tartalom elérhető a stackexchange oldalon, amelyet köszönünk az cc by-sa 3.0 licencért, amely alatt terjesztik.
Loading...