MiSTer frontend future

https://github.com/MiSTer-devel/Main_MiSTer/wiki

Moderators: Mug UK, Zorro 2, spiny, Greenious, Sorgelig, Moderator Team

crocky
Atari maniac
Atari maniac
Posts: 99
Joined: Fri Nov 23, 2018 2:01 pm

Re: MiSTer frontend future

Post by crocky »

Yeah, it is bad when you have a frontend with screenshots / info tab but not all game information is not on it. Not to mention makes it bloat. The current UI is really old school like the NES multi carts back in the 1990s and matches the actual pixilated graphics of most of the cores.
crispycritter911
Atarian
Atarian
Posts: 1
Joined: Wed Oct 17, 2018 12:34 am

Re: MiSTer frontend future

Post by crispycritter911 »

I'd be fine with some eye candy but in reality, I love the prompt boot times. I think what might be a good implementation would be a child mode or wife mode. While, I have no issues navigating menus and loading cores. My wife has problems and I am afraid my kids are going to run a script that would change a video mode or some form of minor inconvenience for me to deal with.

Also do we need to think about a shutdown script? I've haven't had any issues with SD card corruption like with Raspberry Pi. I just didn't know how it was handled? I usually exit the core and go back to the main menu. Then I used a wifi controlled outlet to shutdown my Mister.
hyperterminal
Captain Atari
Captain Atari
Posts: 178
Joined: Sun Jul 09, 2017 1:43 pm

Re: MiSTer frontend future

Post by hyperterminal »

The *.mra files for arcade cores already contain some information that could be displayed in the info tab.

But I agree that the current simple UI should be kept. The responsiveness of the MiSTer, along with its low input lag and accuracy, is one of the main advantages over emulators and should not be watered down.
angelotax
Retro freak
Retro freak
Posts: 11
Joined: Mon Dec 30, 2019 12:52 pm

Re: MiSTer frontend future

Post by angelotax »

wesclemens wrote:
Sorgelig wrote:Laziness is not always locomotive of progress. Sometimes it's pure laziness. You press thousand times while playing the game, don't be lazy to choose the ROM. Especially with recents you can choose it from the short list.
I agree that this isn't really needed. My desire isn't to avoid picking the ROM as you pointed out this is not much effort at all. I just find it inconstant that all the configurations can be saved in the frontend except the default ROM..
I'm with wesclemens on this one. At this point it seems unresonable not to add something like this.
Settings can be easily saved for any core, why not add the possibility to load a default rom or .bin .cue to open at core boot directly in the OSD ?

Also for people with arcade cabs It's crucial to have the possibility to boot a game directly with a core, or directly at system startup without the need to SSH modify. it would be a OSD modification that saves alot of time for alot of different uses. .

And please keep in mind that at this time it's not possible to boot directly a neogeo arcade game.
Also, in main menu core would be lovely to define a .mra or core file to open directly at system boot.

Isn't this project striveing for accuracy and keeping the experience as close as possible ?
For super accurate recreation, Arcade cabinets would need to boot directy in to a game when you power them on, wouldn't them ?

Yeah that's the only modification i would really like to see one day.
Useful and seems not very complicated.
Adds to the consistency of all the cores.
Fixes save states for the rom you choose to start with the core.
Sorgelig
Ultimate Atarian
Ultimate Atarian
Posts: 6348
Joined: Mon Dec 14, 2015 10:51 am
Location: Russia/Taiwan

Re: MiSTer frontend future

Post by Sorgelig »

angelotax wrote:For super accurate recreation, Arcade cabinets would need to boot directy in to a game when you power them on, wouldn't them ?
Where I wrote that MiSTer is for arcade cabinets? If someone put it there - i don't care.
boogermann
Atarian
Atarian
Posts: 6
Joined: Thu Sep 19, 2019 9:35 pm

Re: MiSTer frontend future

Post by boogermann »

Sorgelig wrote:
boogermann wrote:I have been working on a UI and Backend to download cores and change settings for the past 2 months, I'm starting with 320x240 for the UI so people can use with CRT's but there's also gonna be a wide screen version with more stuff being displayed. Here's a sample of it
How this UI is displayed? Is it Linux app or FPGA core?
Short answer: It's a Linux app written in C with SDL 1.2 using the framebuffer.

Now allow me to give you a more complete answer, a timeline of the rabbit hole that lead me to where I'm right now and a little introduction of my self as I didn't want to be bothering you before I had a fully functional solution in hands to present you.

Since this is pretty much my first interaction with you, I just want to get something out of the way and say thank you for everything you do and have done for MiSTer, your leadership on the project is quiet remarkable and some of your workarounds and hacks are truly ingenious, other communities could only dream with some of the features you have implemented on the non FGPA side. Спасибо!!!

Now, I really want to help with the project, I'm still new to FPGA development and HDL, it's my goal for this year, but in the meantime there are countless other areas that I could bring my 20+ years of expertise to help with, specially to lower the entry level for new users, improve the overall user experience and maybe take some load out of your shoulders.

I share the same view as you regarding bloated software like Retroarch/Retropie and one of the things that drove me to MiSTer was the speed and simplicity of it. But after playing a few weeks with it and organizing my collection to the SD card, one thing was still missing for me and that was the ability to have covers associated with the games, it might be an useless feature to some, but for me is essential! I'm a visual person and growing up without knowledge to English or Japanese I relied heavily on cover arts to know what that game was about and in the process it sparked my appreciation for the art, a passion for design and my career. So IMHO I think those arts deserves the same archival purpose and respect of the project as they are tight together and hold an historic artistic representation of the game and a time. Although I started as a Graphical Designer my life instance on not liking to rely on someone else to make what I want done, lead me to be a swiss army knife with a wide range knowledge in different areas.

Some people like to do painting or doodles, I like to express my artistic side doing cover arts and user interfaces. So by the end of September I started to interact with Rysha and Alan on Discord and talk about help with development, as I have done numerous collaborations in the past on with developers from other Homebrew scenes mainly the PSP back in 2005. I then shared a mock up I did keeping the same aesthetic of MiSTer, so it wouldn't diverge too much from the source nor be to complex to be implemented (so I thought), and here is how it looks:

https://i.imgur.com/rpq0AKM.jpg, https://imgur.com/OvHqeK8

Rysha then explained the complexity it would be involved in doing it and most likely you would reject the idea, so I was curious about how hard it would be to implement it myself and dumb enough to try, so I took the task at hand and that lead me on a massive rabbit hole.

But one thing me and Rysha agreed was that the content distribution was a bit lacking making it a bit of a learning curve for new comers, one way I knew I could quickly help was to create a platform agnostic application in Go to simplify the whole process and also a version that runs on MiSTer, I decided to make a PoC and see how it would run on MiSTer, all went well until I hit my first road block when launched through a shell script via the Menu it would fail to open the TTY, so the only way a user could run the application was by opening the terminal and call the application, which would fail it's purpose. I though then about having a light service could stay on MiSTer and have a desktop application to talk to it though a REST Api on the local network, almost akin to how Sony handled the PS Vita with PC users and the CMA, which works but I still find a bit convoluted to need 2 parts to do 1 things.

So I went to research how to write an application that used the framebuffer and tested countless libraries finding all them too complex with one the simplest having to write almost 30 locs just to draw a button, Rysha mentioned SDL2 but that Alan couldn't get to work and that lead me try to get SDL and SDL2 running over DirectFB on MiSTer and I did. I decided to find some game that could be compiled against SDL 1.2 and SDL2 and test lead me to publish a version of Diablo for MiSTer, I then tried to run with SDL2 which has internal scale, so while Diablo runs at 640x480 ok, it get serious performance hits when it's scaled to anything over that. I tried everything under the sun that could make usage of the framebuffer to do UI on a higher level, QT was a high contender but speed and responsiveness is really lacking without some sort of hardware acceleration and the whole things was a bit bloated for something that should be light and fast.

So at that point I knew what MiSTer could handle and it's limitations, so I went to research how it would be the best way to distribute the application.

I used the LXDE you've made available to do the initial compilations and tests before I moved to have it running on the MiSTer side and that got me thinking how were you doing it and what if I could make an image running on top of Alpine Linux and that 5MB image booted just fine in 3 seconds, so now I could ship my application the same way you do with MiSTer and it wouldn't interfere in any way with MiSTer's Linux but at the same time give me access to the /media/fat on my side to download files, change the settings on the MiSTer.ini, etc.

Now I just needed to clone your LXDE_AVHead compile my own RBF to ship with my project and be ready to move on and then I found out about the Altera VIP. I then started to fiddle with DE10_NANO_SOC_FB that comes on the CD and found out that it only runs at 1024x768, I even flirted with the idea of buying a standard license for Quartus so I could always compile the RBF when I needed but the VIP is one of the Mega functions that need separated license and the rabbit hole just got way, way deeper.

So in the process of learning the difference of the MiSTer_FB and the Altera VIP drive you wrote, I noticed the code you implemented to deal with resolution on their drive that is actually part of the code from Main, So now I had to dissect your code to understand how you were doing everything and how everything was tighten together. I deconstructed the Main to understand how it worked and interacted with the Menu Core and that's when it hit me, I can just get away with the license of the VIP if I can make the Menu work as a video card for me, and so I did. I ended up rewriting Main from scratch up to point where it start the video, basically be the missing part to kickstart the MiSTer_FB, this is everything that would be in place on what was the menu.cpp on my project, the vga nag function and this:

Code: Select all

void startVideo(int resolution) {
	video_chvt(resolution);
	video_fb_enable(!video_fb_state());
	exit(0);
}
The balance of this trip is that now I have written a full workflow using Yocto that builds my linux distro with my applications and packages I need from scratch, compiles your kernel, your u-boot, apply patches and pack everything in a way that can be easily automated and in compliance with the way MiSTer operate and does things on a 35mb image. In essence my project is now tightly bonded to MiSTer and can be fully open sourced, as long as there's a Menu core, my application will always work.

I was going way out of way and Rysha pushed me back to help with the core distribution, so now I'm at the point where I'm starting to tighten all the pieces that I need to deliver a complete solution that would put give MiSTer on par with any modern console store front, where you can go in, download the cores you want, update, delete, change settings, enable and disable features that are now in script form, etc. And all that easy enough to setup and deal with that even a monkey would be able to do it, while it could still work as a standalone application that would work just like the LXDE you made, but booting into my UI and when you quit the application and you get you right back into the menu.

Everything that I have done so far I plan to open source and give back to the community in hopes it can become part of the official project and it's being done from scratch around and for the MiSTer and easy for others to help collaborate as well.

The way that I have been writing the UI would make incredible easy to be integrated to Main even with a possibility for let users decided if they want the "traditional" or "modern" interface on the ini file. It's fast and responsive. But that something that could be talked later on as I'm trying to finish the first part of the project.

I'm doing the design around 320x240 and 426x240 so we can have 4:3 and 16:9 and use integer scale.

Here's both views
Image

Here's some of the other things I've done but had mostly shared with people on Discord. https://boogermann.github.io/Bible_MiSTer/ https://ini.misterkun.io/. The Bible is fully written in Markdown so anyone can easily edit. Here's a more elaborated view of a core page: https://boogermann.github.io/Bible_MiST ... ades/1942/ There are more things that I'll show when it's ready and the time is right.

Sorry for the long post :)
angelotax
Retro freak
Retro freak
Posts: 11
Joined: Mon Dec 30, 2019 12:52 pm

Re: MiSTer frontend future

Post by angelotax »

Sorgelig wrote:
angelotax wrote:For super accurate recreation, Arcade cabinets would need to boot directy in to a game when you power them on, wouldn't them ?
Where I wrote that MiSTer is for arcade cabinets? If someone put it there - i don't care.
Dude thanks for what you do but ........... ahahaha !
are u even serious ?
BB
Sorgelig
Ultimate Atarian
Ultimate Atarian
Posts: 6348
Joined: Mon Dec 14, 2015 10:51 am
Location: Russia/Taiwan

Re: MiSTer frontend future

Post by Sorgelig »

Thanks for your lengthy post. I could understand what you want to achieve.
The idea with your app for setting looks good while Main as SDL app doesn't sound good. Currently HDMI output doesn't allow overlays, so menu written as a Linux app will have to be full-screen which is not as handy as OSD and too intrusive. So for menu solution it's not a good move at least for now.
As for distribution, you don't have to make a separate linux distro. You can make a sandboxed environment like it's done for ScummVM and PrDoom using SDL too.
So Settings with nice UI would be good. It can get a special launching from OSD depending how easy it can be installed and how heavy is it. You probably know that MiSTer's Linux is working on read-only file system and additionally reduces (eliminates in the extents) unintentional writes to SD card. So it's not like traditional PC Linux where a lot temporary files are written while working. MiSTer works in "surprise of shutdown" mode. This is one of big difference from RPi and clones.
There is a usual usage scenario: regardless how fancy new UI will be, after some time user stops to notice fancy things and will concentrate on usefulness of features. So if new UI is simply re-worked OSD, then sooner or later user will switch to current lightweight OSD as the main purpose of mister is not showing the pictures but playing the games. You start the MiSTer, quickly choose the core you already know and play the game most likely you know too. So MiSTer is focused around this paradigm.
Also simplicity of catalog (cores,games) makes virtually zero of additional support. So developers can concentrate on coding instead of whistles and bells.

In some future when my thoughts about implementation will be set in the mind, i want to implement OSD overlay getting the graphivs from DDR3 which probably will work equally over HDMI and VGA/DirectVideo. Then more fancy OSD will be possible.

Btw, i also like minimalism in used libraries and keep dependencies minimal. In current Main i use imlib2 which already provides enough graphics functions: loading jpg/png and blending. So basically it should be enough for a simple GUI shown on your pictures. SDL is pretty heavy and bloated from my point of view.

P.S.: All this retro stuff are for 40+ years old users. Current youngsters don't need it. And while time after time young people come here to request some whistles and bells, it's not really what makes MiSTer popular. And it won't make it more popular at all. If you want to compete with RPi then you always will loose on its field. MiSTer is about precise cloning the retro system. There are not many cores and functionality is not as rich as in mame or retroarch.

P.P.S: As a main maintainer of core (not FPGA core term here) components i have to do it in efficient way. Many developers sporadically appear and disappear while i have to maintain the code to prevent the derailing. So MiSTer gives may be minimal whistles and bells, but i think it gives convenient enough framework for other devs to quickly adopt their cores. For user, adding a new core is basically adding of rbf + folder where you put the games and apps for this.
Sorgelig
Ultimate Atarian
Ultimate Atarian
Posts: 6348
Joined: Mon Dec 14, 2015 10:51 am
Location: Russia/Taiwan

Re: MiSTer frontend future

Post by Sorgelig »

angelotax wrote:are u even serious ?
pretty much. MiSTer is targeted for home use on normal HDMI TV with horizontal position. Cabinet features somewhere in the far corner as long as it doesn't make difficulty to use a normal HDMI TV.
Otherwise there is MiST which has VGA only output and no way to rotate the arcades - ideal for cabinets.
angelotax
Retro freak
Retro freak
Posts: 11
Joined: Mon Dec 30, 2019 12:52 pm

Re: MiSTer frontend future

Post by angelotax »

Sorgelig wrote:
angelotax wrote:are u even serious ?
pretty much. MiSTer is targeted for home use on normal HDMI TV with horizontal position. Cabinet features somewhere in the far corner as long as it doesn't make difficulty to use a normal HDMI TV.
Otherwise there is MiST which has VGA only output and no way to rotate the arcades - ideal for cabinets.
Respectfully, everything it's already there, even the "boot to last opened core" functionality in the .ini file.
It's just missing a load default rom/bin/cue in the core options or boot using last .mra in menu core OSD, or even an option in the .ini file "boot to last opened .mra", to be absolute perfection even for arcade cabs.
Would that be such a hard thing to implement ? Just asking..
Sorgelig
Ultimate Atarian
Ultimate Atarian
Posts: 6348
Joined: Mon Dec 14, 2015 10:51 am
Location: Russia/Taiwan

Re: MiSTer frontend future

Post by Sorgelig »

angelotax wrote: Respectfully, everything it's already there, even the "boot to last opened core" functionality in the .ini file.
It's just missing a load default rom/bin/cue in the core options or boot using last .mra in menu core OSD, or even an option in the .ini file "boot to last opened .mra", to be absolute perfection even for arcade cabs.
Would that be such a hard thing to implement ? Just asking..
I think mra can be added to the same "boot to last opened core" function just like rbf. I just never used this option, so not familiar with it. Probably someone can tweak the code to accept the mra.
high5
Atari User
Atari User
Posts: 37
Joined: Thu Dec 27, 2018 10:29 pm

Re: MiSTer frontend future

Post by high5 »

From a technical side, what could a Frontend substitute? Would it only be the core-selection/menu.rbf or would it also be possible to call the frontend within another core (Computer,...) to replace cart/disk/tape-selection?

I personally stick with 2-3 systems when playing around with MiSTer so most of the times I am changing/picking games from within a computer/console core.
Sorgelig
Ultimate Atarian
Ultimate Atarian
Posts: 6348
Joined: Mon Dec 14, 2015 10:51 am
Location: Russia/Taiwan

Re: MiSTer frontend future

Post by Sorgelig »

@boogermann,
not sure if you are interested, but MiSTer Linux has players for different types of audio files: mp3, mod(and many other similar formats), vgm/vgz. So it would be good to have a frontend for music player, so MiSTer can be a music box not only for mp3 but also for different kinds of computer music.
angelotax
Retro freak
Retro freak
Posts: 11
Joined: Mon Dec 30, 2019 12:52 pm

Re: MiSTer frontend future

Post by angelotax »

Sorgelig wrote:
angelotax wrote: Respectfully, everything it's already there, even the "boot to last opened core" functionality in the .ini file.
It's just missing a load default rom/bin/cue in the core options or boot using last .mra in menu core OSD, or even an option in the .ini file "boot to last opened .mra", to be absolute perfection even for arcade cabs.
Would that be such a hard thing to implement ? Just asking..
I think mra can be added to the same "boot to last opened core" function just like rbf. I just never used this option, so not familiar with it. Probably someone can tweak the code to accept the mra.
That's what i hoped, it would be great to have it at some point.
You cold autoboot your cab directly to any PCB revision available within the new Mister arcade system.
Great stuff.
boogermann
Atarian
Atarian
Posts: 6
Joined: Thu Sep 19, 2019 9:35 pm

Re: MiSTer frontend future

Post by boogermann »

Sorgelig wrote:Thanks for your lengthy post. I could understand what you want to achieve.
The idea with your app for setting looks good while Main as SDL app doesn't sound good. Currently HDMI output doesn't allow overlays, so menu written as a Linux app will have to be full-screen which is not as handy as OSD and too intrusive. So for menu solution it's not a good move at least for now. As for distribution, you don't have to make a separate linux distro. You can make a sandboxed environment like it's done for ScummVM and PrDoom using SDL too.
Think of the app right now as what I'm calling "MiSTerNet", a "fpga core store" akin to Nintendo eShop, Playstation Network and so on + a settings menu, my first goal is to have the app act like that but I have been writing it with an eventually possibility of both Main and it being integrated toghether, but I'm not targeting that right now and it's something for the future.

This will give you a better idea of it working.
Image

On it's current form the binary could be easily integrated into Main via a new option like "scripts" or a hotkey like "f9", It would use the same method but instead launch my app. Once a user quits the app he goes straight back to the menu.

The binary itself is sitting right now at around 300kb + if you add the sdl libraries to the linux.img, that would only add a few mbs (all SDL 1.2 libraries compiled for MiSTer sits at around only ~4MBs). I basically have a "gfx pack" with the SDL libraries I compiled targeting MiSTer with a few optimization and enhancements patches applied. Because support for X11, OpenGL and other stuff is removed the library gets really tiny. On the "Linux_Image_creator_MiSTer" I have a gfxlib.tar that gets added to the image the same way you add the addon.tar. This wouldn't hurt the system in any way shape or form as the libraries are just sitting there and doesn't even change the final size of the linux.img as there would still be almost the same amount of space left. (I would even suggest removing Python 2 in the process to free up some space, since it reached the EOL and it's a cancer!)

I don't know if you ever thought about this way, but basically what you created allowing the LXDE to boot in that manner was pretty much turn MiSter in what I called "A Single Docker Machine". I build a lot of containers to ship my applications and microservices. So the idea behind shipping the application on it's separate linux distro would be to have it in a "container", so everything is completely isolated but at the same time tightly integrated with MiSTer though sharing the /media/fat folder. My distro image on it's slim mode has only 8mb :)

I found the way Binary did with ScummVM and Doom a bit convoluted, You download a script, that download a bunch of deb packages (most useless one's that never gets used, like libgl,libcaca,directfb and x11 related), that gets decompressed and installed with some hackery, then throw you back to the menu so you can launch another script that will execute it!

Here is how I have done Diablo for MiSTer: https://github.com/misterkun-io/MiSTer_DeViL
One command to get installed

Code: Select all

wget -qO- https://github.com/misterkun-io/MiSTer_DeViL/raw/master/releases/Arm-DevilutionX_0.5.0.zip | bsdtar -xvf- -C /media/fat/
Or just download and unzip to the root of the SD card.

Ps. If you decide to run, just make sure to add the "vmode -r 640x480 rgb16" to the Diablo.sh, I'll fix that once I update it down the line as I have learned a lot of new tricks since I published that version and I have my own optimized version of the SDL now.
Sorgelig wrote: P.S.: All this retro stuff are for 40+ years old users. Current youngsters don't need it. And while time after time young people come here to request some whistles and bells, it's not really what makes MiSTer popular. And it won't make it more popular at all. If you want to compete with RPi then you always will loose on its field. MiSTer is about precise cloning the retro system. There are not many cores and functionality is not as rich as in mame or retroarch.
I'm around this age, I truly understand your point of view and where you're coming from. But what I'm trying to achieve is not add a bunch of whistles and bells or to compete with other emulator front-ends, but rather an User Interface and User Experience that has being tailored from the ground up for MiSTer to be fast, direct and simple. Think about it this way... in essence my goal is to combining the aesthetic pleasing experience that Nintendo did with it's mini console with the best MiSTer has to offer.
Sorgelig wrote: P.P.S: As a main maintainer of core (not FPGA core term here) components i have to do it in efficient way. Many developers sporadically appear and disappear while i have to maintain the code to prevent the derailing. So MiSTer gives may be minimal whistles and bells, but i think it gives convenient enough framework for other devs to quickly adopt their cores. For user, adding a new core is basically adding of rbf + folder where you put the games and apps for this.
I completely understand you, I truly want to be invested and help with the project. I'm a chief architect by trade, my goal with my work has always being able to give the tools to people so they could focus on what they do better. There is a lot of areas I could help with to take some load of your shoulders so you could focus on more important aspects of the project. Before I got my hands on a DE10-Nano, 2020 was the year I have set to learn A.I, every year I set my self to learn a new language or technology, so HDL has really hijacked my plans to fiddle with AI, I even asked Alan to do a write up on how to port cores from MiST to MiSTer or how to add support for other games that share the same board so I can read the code from mame and try to implement on the FPGA side myself. I think this will be the easiest way for me to start and learn HDL and help him along the way.
Sorgelig wrote:@boogermann,
not sure if you are interested, but MiSTer Linux has players for different types of audio files: mp3, mod(and many other similar formats), vgm/vgz. So it would be good to have a frontend for music player, so MiSTer can be a music box not only for mp3 but also for different kinds of computer music.
I noticed the players, that's something I could easily add to the UI. I was even asking awhile ago how hard would be to implement a VGM player that actually uses the FPGA implementation of the YM2612 or other chips to play the music instead of being software emulated, like this:

[youtube=]https://youtu.be/WoAp2-gWaLM[/youtube]
User avatar
SmokeMonster
Atari nerd
Atari nerd
Posts: 46
Joined: Wed Oct 03, 2018 2:26 pm
Contact:

Re: MiSTer frontend future

Post by SmokeMonster »

Since MiSTer's inception, I've been saying to everyone that I prefer a text menu, for all the reasons Sorge posted above. In no universe did I think I'd say this, but now that I've seen Boogerman's GUI mockup, I'm completely on board with it. Not necessarily because I need or want anything flashy myself, but I just like the pixel-art style and simplicity of it. It's kind a text+ menu, taking advantage of online databases and whatnot.

It's really elegant as a GUI, and I think it would open up a big segment of people who aren't crazy about text menus like us ;D

As I understand it, this front-end would just go in front of the stock MiSTer setup without needing any changes to the project itself? That would be ideal to minimize any upkeep on Sorge's end, and to maintain the exact setup we have now for those who don't want the graphics.
trashuncle
Atari maniac
Atari maniac
Posts: 93
Joined: Fri Jul 05, 2019 9:34 pm

Re: MiSTer frontend future

Post by trashuncle »

No thanks. I like the current layout. I feel this is aimed at a different type of user (general public).
BBond007
Captain Atari
Captain Atari
Posts: 466
Joined: Wed Feb 28, 2018 3:23 am

Re: MiSTer frontend future

Post by BBond007 »

boogermann wrote: I found the way Binary did with ScummVM and Doom a bit convoluted, You download a script, that download a bunch of deb packages (most useless one's that never gets used, like libgl,libcaca,directfb and x11 related), that gets decompressed and installed with some hackery, then throw you back to the menu so you can launch another script that will execute it!

Here is how I have done Diablo for MiSTer: https://github.com/misterkun-io/MiSTer_DeViL
One command to get installed

Code: Select all

wget -qO- https://github.com/misterkun-io/MiSTer_DeViL/raw/master/releases/Arm-DevilutionX_0.5.0.zip | bsdtar -xvf- -C /media/fat/
Or just download and unzip to the root of the SD card.
All of the shared libs required are necessary to satisfy the runtime bindings of the ScummVM. I suggest if you don't believe me then comment out those "useless" libs from the installer script and see if it still runs...

For compliance with the GPL, I think installing required libs from the original unaltered "debs" is a lot better than just bundling a bunch of shared libraries (with ambiguous source) together as a blob. The "debs" contain the various license agreements for each package. I believe this was discussed in the ScummVM thread.

I will check out your DevilutionX port. I am also curious to see how this would run... Thanks!

redsteakraw wrote: Second is making use of meta data and statistics and allowing for people to do things such as show what you played in the last month or year or cores based off of use time. With that data can come to the third making use of that data for opt in sharing allowing to show what is popular what your friends are playing and social network integration.
Even if this was a feature people wanted, I think it would be rather difficult to implement consistently do to the fact that many of the computer cores such as ao486, Minimig, and MSX typically boot a single VHD image containing many applications and games... For example, all (3) of my Facebook friends would think I spent 3 hours playing "BOOT.VHD"
kitrinx wrote: I couldn't disagree more with this. What kind of world do you live in where you have to automatically show people in such detail your game playing habits? Do you also record when you eat meals, or brush your teeth, so facebook can see?
Agreed...
Last edited by BBond007 on Tue Jan 07, 2020 12:58 am, edited 1 time in total.
redsteakraw
Atari freak
Atari freak
Posts: 70
Joined: Fri Dec 06, 2019 6:08 pm

Re: MiSTer frontend future

Post by redsteakraw »

BBond007 wrote: Even if this was a feature people wanted, I think it would be rather difficult to implement consistently do to the fact that many of the computer cores such as ao486, Minimig, and MSX typically boot a single VHD image containing many applications and games... For example, all my Facebook friends would think I spent 3 hours playing "BOOT.VHD"
Well my plan would initially just be a series of linux scripts that interact with a logfile. These scripts could generate pie graphs using gnuplot or simply give you a year in review showing what you played throughout the year. Linux does have tones of things that can be scripted and this won't entail much on the end of the menu other than a log feature. I don't foresee anything too annoying, and this would be opt in if it happens as even if logging is supported it will never be default. As for the computer cores, I don't know much about them and they weren't a main target of this but if a scraper could move their log files to some drive or space the linux drive could read you could get that information but until then yes you would only see the computer core. But in the end these scripts would be up to the creativity and spirit of the community and what scripts can make use of the data. That is basically it, I hope that clarifies my intentions.
boogermann
Atarian
Atarian
Posts: 6
Joined: Thu Sep 19, 2019 9:35 pm

Re: MiSTer frontend future

Post by boogermann »

BBond007 wrote:All of the shared libs required are necessary to satisfy the runtime bindings of the ScummVM. I suggest if you don't believe me then comment out those "useless" libs from the installer script and see if it still runs...

For compliance with the GPL, I think installing required libs from the original unaltered "debs" is a lot better than just bundling a bunch of shared libraries (with ambiguous source) together as a blob. The "debs" contain the various license agreements for each package. I believe this was discussed in the ScummVM thread.

I will check out your DevilutionX port. I am also curious to see how this would run... Thanks!
Next release should have considerable improvements :)
I'm not doubting you in anyway, I'm saying they're useless because they don't get to be used or have any function on MiSTer. They're needed to satisfy because it was compiled with those libraries attached to SDL by default. Say you have a fresh environment and install all your compilers, libraries and etc via apt-get. The SDL that the pack manager downloads will have be compiled with the default settings including support for X11, OpenGL, etc. so if you compile a binary, by default your SDL will be linked to those other libraries to increase compatibility and run in different envoirments. So the difference between my approach and yours is that I'm not installing it from an official package but rather compiling everything from the source. if you LDD my Diablo, you'll that it look for the libraries inside the libs folder and if you ldd any file inside libs, they'll say the current directory is their root directory. Even on my first release there are junk files that doesn't need to be there anymore, but from the release to where I'm right now I've learned how to squeeze every juice out of the ARM processor on the DE10 Nano and optimize those libraries for it. I have a plethora of applications that I was able to make it run at a good speed on MiSTer that I'll ask Sorg later on if it's worth releasing, like DosBox, Quake and many others.

Ps: By the way, there's not much compliance when you're not displaying any license agreements to the user to accept nor keeping the copyright files in there. I'll let your code echo for itself.

Code: Select all

echo "Deleting junk..."
for JUNK_FILE in "bug" "doc" "lib" "lintian" "menu" "share";
I'm not sure if you're aware, but the doc folder is where all README, AUTHORS, Copyright, TODOs, Credits, etc go... So with all due respect don't try to be a white paladin and lecture me about compliance or license agreements when you're just throwing those words around, I don't see a mention to sources, links to any of the projects nor credits on the readme of your repository. And please don't take this the wrong way as I respect you and the help you gave me when I was researching the subject in the beginning and I'll be more then happy to help you back if you want some improvements on your releases.
boogermann
Atarian
Atarian
Posts: 6
Joined: Thu Sep 19, 2019 9:35 pm

Re: MiSTer frontend future

Post by boogermann »

Sorgelig wrote:@boogermann,
not sure if you are interested, but MiSTer Linux has players for different types of audio files: mp3, mod(and many other similar formats), vgm/vgz. So it would be good to have a frontend for music player, so MiSTer can be a music box not only for mp3 but also for different kinds of computer music.
I put something together here pretty quick here to have an idea of space and how it would look, behold the MiSTer Game Music Player!!!
Image
how do you like it? ;)
LewisD
Retro freak
Retro freak
Posts: 10
Joined: Wed Nov 28, 2018 6:17 pm

Re: MiSTer frontend future

Post by LewisD »

While I like boogermann’s front end concept, I really think the community should focus on improving the current OSD as much as possible before moving on to more drastic design changes. Perhaps the following can be added:

- More end-user customization options. Similar to changing fonts, give users the ability to change the color of the font and OSD window background away from the standard burgundy and white scheme.

- Offer end-user the ability to widen the OSD window if using a 16:9 TV/monitor so that game titles and other text isn’t cut off on the right.

- Integrate a universal settings menu into the OSD that is similar to the ini_settings script.

- Integrate the updater script into the OSD

- Add an indicator icon to the top of the OSD (near the WiFi/Bluetooth icons) that alerts the end-user that updates are available (assuming they are connected to the internet).

I’m not technically versed in the inner workings of the MiSTer hardware/software, so my ideas could be totally off-base. Hopefully these are some ideas that could be implemented.
ReedSolomon
Atari nerd
Atari nerd
Posts: 47
Joined: Tue Oct 09, 2018 1:52 am

Re: MiSTer frontend future

Post by ReedSolomon »

boogermann wrote:I put something together here pretty quick here to have an idea of space and how it would look, behold the MiSTer Game Music Player!!!
Image
how do you like it? ;)
That's a pretty cool concept. I agree that it'd be cool to be able to launch players from Mister Main for various cores that use the actual FPGA chips. C64 SIDS, Gameboy sound files, etc. Mister could be a great front end for playing vgmusic as accurately as possible.
flain
Atari User
Atari User
Posts: 35
Joined: Sat Nov 03, 2018 6:21 am

Re: MiSTer frontend future

Post by flain »

Couldn't we just add an auto launch function to MiSTer to launch boogermans menu? That way you could keep the normal OSD, and those who want to use boogermans menu just set something in the ini file?

[MiSTer]
autolaunch=boogerman-menu.something
crocky
Atari maniac
Atari maniac
Posts: 99
Joined: Fri Nov 23, 2018 2:01 pm

Re: MiSTer frontend future

Post by crocky »

I like idea of autolaunch, I dont want to be forced to change the current OSD.

Edit: The MGM Player looks fantastic!!! Please give us that :D
Locked

Return to “MiSTer”