Author Topic: Fade to Black (f2bgl) *experimental*  (Read 2437 times)

gameblabla (OP)

  • *
  • Posts: 454
Fade to Black (f2bgl) *experimental*
« on: September 26, 2016, 05:19:48 am »

Johnny actually resumed work on f2bgl. (and a better version than this release)
This version is actually not finished and can be buggy in some places.
You have been warned.

Here's a port of Fade to Black using f2bgl.
This is based on Johnnydude's modifications and the latest git version. (converted from SDL2 to SDL1)
He strangely decided not to release his version, probably because it was too unstable
The game runs at a decent pace but it can still crash from time to time.

Put the game in .fadetoblack, in your home directory.
The game is provided with the demo files inside :
If it can't find the full game at that location, it will load the demo files from the OPK instead.

Controls
A to Jump
B to shoot
X to Pull gun
Y to Open/Use
L to Walk
R to Recharge
Start for Inventory

Download
https://github.com/gameblabla/f2bgl/raw/master/f2bgl.opk

(and no qubits, i have not given up on temper, it is just taking a lot of time...)
« Last Edit: September 27, 2016, 08:51:16 pm by gameblabla »

kaio

  • *
  • Posts: 213
    • All about GCW-Zero on Russian + Repo
Re: Fade to Black (f2bgl)
« Reply #1 on: September 26, 2016, 08:57:09 am »
Thanks!
GCW-Zero | JXD S602

Mar8

  • *
  • Posts: 103
Re: Fade to Black (f2bgl)
« Reply #2 on: September 26, 2016, 10:16:40 pm »

(and no qubits, i have not given up on temper, it is just taking a lot of time...)

Hahahahha!

johnnyonflame

  • *
  • Posts: 212
Re: Fade to Black (f2bgl)
« Reply #3 on: September 27, 2016, 07:59:01 pm »
Hey! I'm happy you took interest in my changes to f2bgl. I was working on this as a test-case for theories I had on OpenGL ES bottlenecks on the GCW0. There are -many- reasons why I never really released any of this. There's even code I took from other people such as the eglport.cpp gluecode.

I'm active on IRC, and I would've loved to talk to you about it. Overall I'm not really happy about the state of this release, and there are some concerns over the way you introduced the changes to your sources. Mind chatting with me for a while?

senutar

  • *
  • Posts: 1
Re: Fade to Black (f2bgl)
« Reply #4 on: September 28, 2016, 08:55:58 am »
I was working on this as a test-case for theories I had on OpenGL ES bottlenecks on the GCW0. There are -many- reasons why I never really released any of this.

@johnnyonflame could you share with us what bottlenecks you found? I'm also working on a gles based game. So it would be great to know which practices are better avoided.

gameblabla (OP)

  • *
  • Posts: 454
Re: Fade to Black (f2bgl)
« Reply #5 on: September 28, 2016, 11:04:19 am »
Quote
@johnnyonflame could you share with us what bottlenecks you found? I'm also working on a gles based game. So it would be great to know which practices are better avoided.
Well, it's mainly due to the crappy driver, etnaviv, that is not very fast and worst of all, not very compliant and very buggy.
(even the pandora has this issue)
In this case, a software renderer like TinyGL/TinyGLES should run faster than the native opengles driver.
If you are looking for another OpenGL-like software renderer, there's also nGL by Vogtinator :
https://github.com/Vogtinator/nGL

In fact, he switched to a software renderer for his f2bgl port he's currently working.

pcercuei

  • ***
  • Posts: 1397
    • GitHub
Re: Fade to Black (f2bgl) *experimental*
« Reply #6 on: September 28, 2016, 01:03:33 pm »
Well, it's mainly due to the crappy driver, etnaviv, that is not very fast and worst of all, not very compliant and very buggy.

Ok, first of all, calling a reverse-engineered driver "crappy" is a bit insulting.
Then I would like to clear something up:
- etnaviv is fast, works quite well, and not that buggy. The binary blobs were much worse  ;D
- this is an mobile GPU we're talking about. You can't expect to program it like you would do for a desktop GPU, and expect it to work. Using VBOs and batching the calls would be a good start.

johnnyonflame

  • *
  • Posts: 212
Re: Fade to Black (f2bgl)
« Reply #7 on: September 28, 2016, 08:01:21 pm »
@johnnyonflame could you share with us what bottlenecks you found? I'm also working on a gles based game. So it would be great to know which practices are better avoided.

Mostly memory bandwidth and API overhead related, as it is to be expected, but in the GCW Zero it's a little bit more pronounced than I expected at first.

The most important step to achieve good performance is batching draw-calls as much as possible, on the GCW Zero these are very costly, and avoid texture uploads on real-time, most of the work I've done were related to reducing drawcalls and texture uploads.

https://github.com/JohnnyonFlame/f2bgl-optimized/commits/master

gameblabla (OP)

  • *
  • Posts: 454
Re: Fade to Black (f2bgl) *experimental*
« Reply #8 on: September 28, 2016, 10:05:18 pm »
Well, it's mainly due to the crappy driver, etnaviv, that is not very fast and worst of all, not very compliant and very buggy.
Ok, first of all, calling a reverse-engineered driver "crappy" is a bit insulting.
Then I would like to clear something up:
- etnaviv is fast, works quite well, and not that buggy. The binary blobs were much worse  ;D
- this is an mobile GPU we're talking about. You can't expect to program it like you would do for a desktop GPU, and expect it to work. Using VBOs and batching the calls would be a good start.
Of course, i'm not saying it is complete trash but it could have been so much better, plus it doesn't support all the OpenGL ES 2.0 features, even though the hardware does.
For example, i have ported MKXP to the GCW Zero and the textures were lacking transparency and it was pretty slow. (before quickly crashing)
The same code on the Pandora works with much less issues. (but you may have to switch between several drivers, which is lame)

I'm sure the binary blobs were worse but etnaviv isn't much better.

I'm surprised the slow SD-RAM memory is responsible for the slowdowns though.
(using opengles probably requires faster memory than the old sdram on old ms-dos computers, for which Fade to Black was released)

congusbongus

  • *
  • Posts: 74
    • congusbongusgames
Re: Fade to Black (f2bgl) *experimental*
« Reply #9 on: September 29, 2016, 01:22:17 am »
textures were lacking transparency
Sorry to go on a tangent, but does this apply to SDL2 textures too? That they don't support semi-transparency? What about full transparency?

gameblabla (OP)

  • *
  • Posts: 454
Re: Fade to Black (f2bgl) *experimental*
« Reply #10 on: September 29, 2016, 07:04:40 am »
textures were lacking transparency
Sorry to go on a tangent, but does this apply to SDL2 textures too? That they don't support semi-transparency? What about full transparency?
Sorry but i have not tested extensively SDL2 on the Zero but i don't think SDL2 is affected on the zero.
Someone though reported that rotations do not work using SDL_RenderCopyEx....
I don't understand why pcercuei is saying that etnaviv works quite well. (plus the author stopped working on it last time i checked)

pcercuei

  • ***
  • Posts: 1397
    • GitHub
Re: Fade to Black (f2bgl) *experimental*
« Reply #11 on: September 29, 2016, 09:41:38 am »
I don't understand why pcercuei is saying that etnaviv works quite well. (plus the author stopped working on it last time i checked)

You're talking shit about what I consider a masterpiece of engineering. Besides, you tend to forget that what we have on the GCW Zero is a two-years-old snapshot of the userspace etnaviv driver, with the crappy kernel driver from Vivante. Since then it changed so much. And yes, it's still actively developped, and it's to be merged soon: http://phoronix.com/scan.php?page=news_item&px=Etnaviv-Libdrm-Merged

gameblabla (OP)

  • *
  • Posts: 454
Re: Fade to Black (f2bgl) *experimental*
« Reply #12 on: September 29, 2016, 09:23:47 pm »
You're talking shit about what I consider a masterpiece of engineering.
I didn't personally insult you so i don't know why you should show me a lack of respect.
Using the current firmware, the bugs are there and they can't be denied.
If it got fixed upstream (i actually saw that phoronix news but i had not checked if you merged the changes), then great,
i'll check them when the next stable firmware will get released.

I'll let johnny work on it, i'm no longer interested in f2bgl.

pcercuei

  • ***
  • Posts: 1397
    • GitHub
Re: Fade to Black (f2bgl) *experimental*
« Reply #13 on: September 30, 2016, 09:58:10 am »
Where did I lack respect for you? I didn't intend to.
We can't switch to the upstream etnaviv, we need a KMS driver before that. That's why we're stuck with a 2-years-old version full of bugs, that doesn't reflect the current state of the etnaviv project.

gameblabla (OP)

  • *
  • Posts: 454
Re: Fade to Black (f2bgl) *experimental*
« Reply #14 on: October 01, 2016, 09:40:50 am »
Where did I lack respect for you? I didn't intend to.
We can't switch to the upstream etnaviv, we need a KMS driver before that. That's why we're stuck with a 2-years-old version full of bugs, that doesn't reflect the current state of the etnaviv project.
Then i cannot wait for the new KMS driver because i have a huge stack of software (MKXP, Picolove...) that currently doesn't work due to the old version of etnaviv being used.