› Foros › Multiplataforma › Consolas alternativas
naxeras escribio:
No te lo tomes a mal pero si no sabes de algo mejor no decir nada en vez de lo primero que se te pase por la cabeza.
Luego la gente se cree las cosas y acaba desinformada o con una información que nada tiene que ver con la realidad.
Un Saludo.
Consoles have hit customs and are in the clearing house as we speak from past experience they should be cleared Monday or Tuesday. Once cleared they usually take one to two days to arrive here according to what time of day they were cleared.
The developers think they have found the cause of the stutter in video and audio and are working diligently to resolve the issue. I will keep you posted with updates as I get them on this progress.
The video of a test kernel recognizing 512MB was one of the surprise videos a few others are still in development and will be shown also very soon. These new surprise will probably be after the units ship but it will be some exciting stuff.
hi-ban escribió:El Sonic 3 en la Dingoo va a 33-37 fps ingame (acabo de probarlo).(
Wence-Kun escribió:A todo esto, yo actualmente estoy bien servido con mi JXD S602b, pero si el caso fuera recomendarle (o recomendarme xD) a alguien la compra de una GCW, qué puntos dirías que son los fuertes o importantes de la consola?, qué la hace tan especial?
Wence-Kun escribió:A todo esto, yo actualmente estoy bien servido con mi JXD S602b, pero si el caso fuera recomendarle (o recomendarme xD) a alguien la compra de una GCW, qué puntos dirías que son los fuertes o importantes de la consola?, qué la hace tan especial?
hi-ban escribió:No, en el emulador de Lion (la version mas nueva), con overclock a 400mhz:
Con rendering "accurate" va a 33-37fps.
Con rendering "fast" va a 47-51fps, pero hay graficos que no salen como deberían salir.
Con rendering "best" va a 30-36fps.
Sonido a 22050 Hz, stereo.
A lo mejor es que has puesto en opciones, en show fps mode: "emulated". Para ver los fps reales tienes que ponerlo en "rendered".
En cuanto a diseño es mucho mas bonita que el resto de las consolas vistas hasta la fechaWence-Kun escribió:A todo esto, yo actualmente estoy bien servido con mi JXD S602b, pero si el caso fuera recomendarle (o recomendarme xD) a alguien la compra de una GCW, qué puntos dirías que son los fuertes o importantes de la consola?, qué la hace tan especial?
hi-ban escribió:naxeras, es verdad, es que tenía activado el escalado fullscreen, y me bajaba bastante el rendimiento (que no se para que lo pongo. total, para 8 pixeles por arriba y otros 8 por abajo...)
KFR escribió:En cuanto a diseño es mucho mas bonita que el resto de las consolas vistas hasta la fechaWence-Kun escribió:A todo esto, yo actualmente estoy bien servido con mi JXD S602b, pero si el caso fuera recomendarle (o recomendarme xD) a alguien la compra de una GCW, qué puntos dirías que son los fuertes o importantes de la consola?, qué la hace tan especial?
La pantalla es 4:3 cosa que "ninguna" otra lo es pero que "todos" los juegos retro si lo son
La pantalla tambien cuenta con una resolucion de 320x240, muy cercana a las originales de sistemas retro
Soporta, mediante la conexion usb otg, conectar incluso cuatro perifericos al mismo tiempo
Salida tanto hdmi como analogica para conectar a un televisor
La bateria en comparacion a un sistema con android durara mucho mas
Acelerometros ademas de vibracion
Wifi que se puede usar para juego directo entre consolas
naxeras escribió:Esta claro, a ver si despega y sacan cosas chulas.
Yo a la GCW pido lo que no me da una dingoo:
[*]PSX Full Speed.
[*]MAME4all Full Speed.
[*]FBA Full Speed.
[*]GBA Full Speed
[*]SNES Full Speed
[*]Dosbox algo más rápido que el que se ha visto en vídeos que no mueve ni Alone In The Dark al 100% (¿Esto último no debería ya de pasar con el update de la GPU?).
Escalado bilinear para todos los emuladores de resolución inferior y que mantenga la relación de aspecto.
Sigo soñando jajajaja
Un Saludo.
Project Update #42:Status Update May 9th, 2013 GCW-Zero: Open Source Gaming Handheld by Justin Barwick
At 9:45PM the shipment was cleared from customs no movement as of yet but the shipment has cleared customs finally...
Next here is a video of some of the great things now working on the console. We also now have the video driver working in 16bpp which means when playing games they get 60fps on average now.
Now for video:
http://www.youtube.com/watch?v=RvL2pmIr ... mklAjxuHtA
Hey, you guys are doing great! Looks like I might get my Zero earlier than I expected. Here was the breakdown of my expectations when the Kickstarter wrapped up.
March - AHHAHAHAHA! N00bs.
April - Terribly unlikely
May - Highly doubtful
June - Best case scenario
July - When I actually expect to get it
August - Crap! Really didn't want to wait this long.
September - Oh, no! It's Pandora, part II!
evilquake escribió:Me gusta como carga los juegos de psx http://www.youtube.com/watch?v=Pnpaor4mzfA
alexei_gp escribió:evilquake escribió:Me gusta como carga los juegos de psx http://www.youtube.com/watch?v=Pnpaor4mzfA
Lol ese video yo lo subi a youtube el uploader original le borraron el video ni se molesto en subirlo de nuevo... a ver cuanto me dura asi que si alguien quiere una copia bajenlo de inmediato de youtube xDDDDDD
naxeras escribió:alexei_gp escribió:evilquake escribió:Me gusta como carga los juegos de psx http://www.youtube.com/watch?v=Pnpaor4mzfA
Lol ese video yo lo subi a youtube el uploader original le borraron el video ni se molesto en subirlo de nuevo... a ver cuanto me dura asi que si alguien quiere una copia bajenlo de inmediato de youtube xDDDDDD
Probablemente lo haya borrado el propio autor ese vídeo no es de la GCW, la GCW no tiene emulador de PSX de momento.
Un Saludo.
evilquake escribió:Pero es un prototipo de la consola, y puede cargar Psx, no se supone que la original debería o podría cargar Psx sin problema?
Project Update #43: Status Update May 13th, 2013
Shipment hit the Kansas City Hub at 6:30PM tonight and is slated for delivery tomorrow I will try to get off in time to receive the package if not able due to work will make request for early day Wednesday to get shipment
An Update from Justin off the KS Page:
I've not with-held information the SE were held because of the stutter bug and testing of the kernel to ensure it was resolved.
Now that it is confirmed flashing will start with first priority to the SE models then the KS. I've stated this on the updates section also not more then a couple days ago. I've also let numerous people via IRC and e-mail from the SE group know these same answers.
Flashing will commence of Friday and carry on till all SE units then KS units are flashed the SE units will be shipeed first followed by the KS.
All European orders will be shipped to the retailer in bulk to be shipped out to each kick starter pledge from the UK.
Hamunaptra escribió:Para cuando pensais que estara en venta en tiendas? Mayo es el mes no?
Tiene muy buena pinta.
De los foros de Dingoonit escribió:Changelog:
Kernel:
The kernel is now based on Linux 3.9
Fixed the corruption on the data partition that used to occur during online resizing
For the hackers out there, the serial line now outputs the kernel's debug messages
The framebuffer driver now supports 16bpp pixel mode, as well as 32bpp pixel mode
Double buffering has been implemented; compile your apps with SDL_HWSURFACE | SDL_DOUBLEBUF to get the maximum performance
The LCD now refreshes at a perfect 60 Hz (it was more ~58 Hz before)
VSYNC has been implemented. SDL will automatically wait for the vertical refresh inside SDL_Flip(), provided you compiled your app with SDL_HWSURFACE | SDL_DOUBLEBUF. This means: no more tearing
RootFS:
Pwswd now uses a INI-like configuration file. If you created your own shortcuts, you may have to remove /etc/local/pwswd.conf
The "power off" shortcut has been disabled by default; now, the device will turn off if the power slider is pressed for more than 3 seconds
The SD cards are now mounted with the UTF8 option by default
SDL_image is now in version 1.2.12
SDL_mixer is no longer linked to libmad, which is GPL (that obliged all apps using SDL_mixer to be GPL too)
The FAT partitions are mounted with a shorter flush delay, which reduces the risks of corruption if the partition if not cleanly unmounted
Added a library, "libini", that can be used to read INI-like configuration files. Python bindings are also provided
SDL has been fixed to work correctly with double buffering, when a lower resolution is used (e.g. 320x200)
Bootloader:
Boot speed increased from 3.8 seconds to a couple of milliseconds
Enabled debug output on the serial line
Misc.:
The update process is now much more robust and secure. It verifies that the rootfs and kernel are not corrupted before updating. If the update process fails, it won't leave your OS in a bad state. Finally, if for some reason the new version of the OS doesn't boot or has issues, you can boot the old version of the kernel and rootfs pressing X / Y respectively
All the Zeros out there currently have a ~16 MB kernel partition, and a data partition formatted with sub-optimal options. The SE and KS units will have a ~400 MB kernel partition, but more space on their data partition (magic!) thanks to better formating options. This is currently not an issue for Frankenzeros users. When the time will come, a tool will be created to switch to the new format.
Known issues:
It is recommended to set the "screen timeout" on gmenu2x to 0. Having the screen turns off while files are transferred via USB may lead to a complete crash of the OS.
VSYNC acts as a frame limiter: the apps compiled with double buffering won't go above 60fps. This can be a problem with some games as it disturbs their own frame limiter (based on sound output or timers). The proper fix is to disable the app's frame limiter.
With VSYNC, the apps that can't push 60 frames per second will be limited to 30fps (frameskip 1). This isn't bad in itself, because a game running at a constant 30fps looks much better than one running at a variable rate between 30fps and 60fps. The problem is that some apps that have frameskip (as in, almost only emulators, but thanksfully only some of them) may be disturbed by this, as they do not expect to be limited to 30fps.
Because of the previous point, the games that don't run at 60fps natively (i.e. 50Hz PAL games) will drop to 30fps... A future update will add a 50Hz mode to address the issue. In the meantime, the apps that need to output at 50fps (and only those ones. Go fix your code!) can be compiled without SDL_DOUBLEBUF to disable the VSYNC. But you'll cry your eyes out because of the tearing...
KFR escribió:Lo del problema de la limitacion que añade el uso de vsync junto con la de los propios juegos/emuladores, haciendo que titulos pal a 50 se vean capados a 30...es lo que menos me ha gustado de todo. El resto en general pinta bien o muy bien.
VSYNC acts as a frame limiter: the apps compiled with double buffering won't go above 60fps. This can be a problem with some games as it disturbs their own frame limiter (based on sound output or timers). The proper fix is to disable the app's frame limiter.
With VSYNC, the apps that can't push 60 frames per second will be limited to 30fps (frameskip 1). This isn't bad in itself, because a game running at a constant 30fps looks much better than one running at a variable rate between 30fps and 60fps. The problem is that some apps that have frameskip (as in, almost only emulators, but thanksfully only some of them) may be disturbed by this, as they do not expect to be limited to 30fps.
Because of the previous point, the games that don't run at 60fps natively (i.e. 50Hz PAL games) will drop to 30fps... A future update will add a 50Hz mode to address the issue. In the meantime, the apps that need to output at 50fps (and only those ones. Go fix your code!) can be compiled without SDL_DOUBLEBUF to disable the VSYNC. But you'll cry your eyes out because of the tearing...
KFR escribió:Aqui va la parte importante..VSYNC acts as a frame limiter: the apps compiled with double buffering won't go above 60fps. This can be a problem with some games as it disturbs their own frame limiter (based on sound output or timers). The proper fix is to disable the app's frame limiter.
With VSYNC, the apps that can't push 60 frames per second will be limited to 30fps (frameskip 1). This isn't bad in itself, because a game running at a constant 30fps looks much better than one running at a variable rate between 30fps and 60fps. The problem is that some apps that have frameskip (as in, almost only emulators, but thanksfully only some of them) may be disturbed by this, as they do not expect to be limited to 30fps.
Because of the previous point, the games that don't run at 60fps natively (i.e. 50Hz PAL games) will drop to 30fps... A future update will add a 50Hz mode to address the issue. In the meantime, the apps that need to output at 50fps (and only those ones. Go fix your code!) can be compiled without SDL_DOUBLEBUF to disable the VSYNC. But you'll cry your eyes out because of the tearing...