PS2 (WIP) XtremeEliteBoot+ (a powerful alternative for FMCB)

still, we will have an issue with the aspect ratio

You're in charge here.
You can also add ifcaro OPL.
You can only include other forks, because they have some valuable additional options.

It's up to you to decide.
 
wtf are you saying @HWNJ opl db is not interfereing with your app you are the one interfereing with there app telling them to change something most people are used to figure out a way to use a different folder instead of INTERFEREING WITH OPL DB they only care on what is best for opl soo i think they're not gonna do what you want if it is bad for opl you need to know that opl has the priority i recommend you find a way around and STOP INTERFERING WITH OPL.
i can code hello world....but you can't even code your own boot loader.....
 
@HWNJ: Why don't you change your OPL-Theme, to use the scaling-functions of the theme-engine?

The scaling is aligned to a 640*480 'render/scaling-grid'! ;)

Just add the scaling-factor to the PS1-related 'name/function' in the Theme-Config and you could force it to look pretty much the same on all VModes... and you can 'form' a 16:9-picture (i.e. Art, etc.) to a 1:1-picture-format, or vice versa...
 
wtf are you saying @HWNJ opl db is not interfereing with your app you are the one interfereing with there app telling them to change something most people are used to figure out a way to use a different folder instead of INTERFEREING WITH OPL DB they only care on what is best for opl soo i think they're not gonna do what you want if it is bad for opl you need to know that opl has the priority i recommend you find a way around and STOP INTERFERING WITH OPL.
I said (a lot of time ago and before that change was made to OPL) that PSXtreme will also be linked with OPL. Then they changed that without thinking on how it will affect other applications.

Why don't you change your OPL-Theme, to use the scaling-functions of the theme-engine?
On the original OPL, there's no way to fix that as the PSX page (with different settings for art) is only available on OPL-DB.

Anyway, I said that you all will have the BETA to see what I am talking about.
Then, all of you will also request that change to be done.
On PS2-Home, they are forgetting that different POPStarter builds haves different compatibility and PSXtreme deals with it, which OPL DB does not.
 
I said (a lot of time ago and before that change was made to OPL) that PSXtreme will also be linked with OPL.
  1. First of all,... 'OPL' does not support PSX/POPS/etc., so why would it ('PSXtreme') be 'linked' to it? I suppose you mean 'OPL-DB'?!? If so, please use the correct acronyms, to avoid confusion!
  2. OPL is the app, all of the other applications 'surround' and support, so naturally these apps need to be updated to the changes in OPL(-DB) and NOT vice versa... That's just not the way it works!
  3. This would still not stop you, from doing that change on your own... (Common... even if you would need to do that on every new revision, it would merely take minutes [including compilation])
  4. The change you suggest is structurally bad... A combination of looking up both (VCDs and cfg) would be sufficient, to resolve the problem, while keeping it as easy for the end user as it is...
  5. Why would anyone use the old method of installation (i.e. via the tool), instead of simply using the new veriation? Why? There's no benefit to it at all, AFAIK.
Then they changed that without thinking on how it will affect other applications.
WTF?!? OPL(-DB) is the main-app and your tool is there to support it! Logic permits, that YOU have to update your tool(s), if you intend to support newer versions (like @danielb does with OPLM)!

They don't have to care about any of the supporting companion-apps, but solely about the integrity of the structure of THEIR program, which is exactly what you should do as well...

On the original OPL, there's no way to fix that as the PSX page (with different settings for art) is only available on OPL-DB.
  1. This fix is not in any way related to the OPL-fork (OPL [ifcaro], OPL-DB [Jay-Jay], or any of the other OPL-Forks), but solely to the support of it in the theme-engine, which has been added a long time ago...
  2. The same scaling can be applied to the PS2-Games-Pages and the Apps-Page...
  3. That very same scaling can definetly also be used/done on/to the PS1-Page, because it's internal theme (Yes, OPL has that!) in OPL-DB does something similar...
Anyway, I said that you all will have the BETA to see what I am talking about.
Then, all of you will also request that change to be done.
I still don't get, why you don't simply create another OPL-Fork... You can make one initial commit with this exact change you wanted and then can still back-merge all changes/updates of OPL(-DB) to your build easily.

On PS2-Home, they are forgetting that different POPStarter builds haves different compatibility and PSXtreme deals with it, which OPL DB does not.
O.k.?!
 
Could you please explain why they have to change their path? Why can't you get your software to share the same directory? It implies that your software works in some incompatible way, but why can't it be made to work with that fork of OPL? Like how we design OPL to be backward and forward-compatible with USBExtreme.

I am still not in support of that forum's work because of the people, but simply creating another fork will mean mean more work and OPL cannot just be updated by the user. It may not be a very good idea.

Look at how ps2netbox made the ps2netbox. The idea was to just earn some money and leave it as it was... now it has stagnanted. Since it uses a custom version of OPL that required his proprietary drivers, nobody can just update it. And he did not seem willing to continue its development.
Of course, if you are willing to support your OPL users throughout the lifespan of XEB+, that works too.
 
Ok guys, just read the OPL-DB thread and totally agree with Jay-Jay... It is counter sense to change OPL to use cfg files for VCD's due to a project that is not yet released... @HWNJ, Why don't you release your app beya testing version using an older version of OPL that supports cfg files? Convince the guys with such version and then you can use Jay-Jay empowerment to change OPL, or support you in change XEB+ in a way that you don't depend on OPL to release news... Maybe.
 
First of all,... 'OPL' does not support PSX/POPS/etc., so why would it ('PSXtreme') be 'linked' to it? I suppose you mean 'OPL-DB'?!? If so, please use the correct acronyms, to avoid confusion!
OPL-DB, sorry...
This would still not stop you, from doing that change on your own... (Common... even if you would need to do that on every new revision, it would merely take minutes [including compilation])
That's why I said I will still release a BETA and wait for them to do the necessary changes to OPL-DB.
Once they see how PSXtreme works, they will understand why that change is necessary.
WTF?!? OPL(-DB) is the main-app and your tool is there to support it! Logic permits, that YOU have to update your tool(s), if you intend to support newer versions (like @danielb does with OPLM)!
I can update PSXtreme, but without POPStarter's code, I can change his behavior and PSXtreme handles POPS and POPStarter.
I still don't get, why you don't simply create another OPL-Fork... You can make one initial commit with this exact change you wanted and then can still back-merge all changes/updates of OPL(-DB) to your build easily.
Because the SDK I use to compile XEB can not compile OPL due to library differences
Could you please explain why they have to change their path? Why can't you get your software to share the same directory?
Because of the way POPStarter works. That's the issue.
@HWNJ, Why don't you release your app beya testing version using an older version of OPL that supports cfg files? Convince the guys with such version and then you can use Jay-Jay empowerment to change OPL, or support you in change XEB+ in a way that you don't depend on OPL to release news... Maybe.
I said I will do that. I just need to do some changes on XEB+ following some recommendations regarding compatibility by @sp193
 
Thank you very much for the answer my dear, so we are waiting for the backstory of Popstarter, I think there is still a lot we could have in this great project.
 
Current status is: "some day in this year, maybe"... So let's stop aslask for estimates.

Have not seen this, link?

Also, Lets not tell me what to do, ahaha, i don't go to your place and tell you what to do, lol :)
(just kidding) Normally i would agree and say lets not ask, but there has been many cliffhangers and it was just last week this estimate was made after various things.. The dev was here posting yesterday and was kind of surprised we did not see anything posted about this since it was the date given last week. Normally i say give time but its been dragging on for a long while now, so hopefully some news is coming...?..? ..


edit:
Ahh i see the note in the OP (i believe that estimate is an older addition)
i was speaking of the latest estimate posted below
 
Last edited:
read the entire post:
http://www.psx-place.com/threads/co...lternative-for-fmcb.15471/page-16#post-144419
I said "I was intending to" and "I will wait for two reasons" and one of them is:
"2-@sp193 enlight me about something that can bring compatibility to other PS2 models in a private conversation thread"
I did read the entire post and only delay was pertaining to the 1 week beta, at least that is how i read it :). Obviously you know the ETA best but that is what i though by reading this below.

I was intending to come here today and release a 1 WEEK BETA for everyone to try and burst-out before the release 2018-11-10, so I can gather some feedback and pulish everything.

I will wait for two reasons:
1-There's an public-known app interfering with some of the XEB+ apps.
I will not publicly release the FULL XEB+ until this is fixed. Period. (The BETA will be released anyway)
2-@sp193 enlight me about something that can bring compatibility to other PS2 models in a private conversation thread:
 
Last edited:
Why don't you make a closed beta-test? You asked for them and a multitude of people have responded...

If you (have) fear, someone would leak it... Well... I did not want to ask, but multiple users on multiple forums/boards say, I would be a good candidate.


So as for a reference... Do I leak stuff? No... I told Jimmikaelkael I will upload/disclose the Source of at least FMCB 1.8b, after a certain amount of time and I did so (~9 years).

It's the same for your project... and I suppose you would release it way earlier than I would 'leak' it (if any at all).


@sp193 and/or I, probably would be your hardest judge(s), but I am the smart-ass and he's the gentle guy. ;) lol
 
Because of the way POPStarter works. That's the issue.

That is what I do not understand. POPS was meant to be used from the HDD unit, booted directly by the HDD Browser.
When kHn used it in the POPStarter project, we got more freedom to how we can use it. But it still had no front end.

That conf_elm.cfg file you wanted, is a ps2-home thing. In fact, kHn was checking if it existed at some point, just to block the ps2-home fork. Hence how it got renamed to conf_elmz.cfg, to work around the ban.

They don't (and should not) dictate how POPStarter is to be used. There was never a standard way to use POPStarter with any particular front-end.

But if you feel that you want your users to be able to switch between your work and their variation of OPL, you could shape your work to be compatible with what they use. There is no other reason for collaborating with them otherwise, IMO. But OPL is first and foremost a PS2 game loader.
 

Similar threads

Back
Top