Tool QSP QSP Player With Video Support Written In Qt

[Deleted member 1252738]

As long as that data isnt constantly changed/edited/added by others there is simply no need to use json at all.

Unfortunately the nature of what we're doing is to allow even non-coders to modify and/or add their own slave data and/or path data for graphics.

Sonnix's player allows usage of javascript which means that json files can be read via eval commands in javascript - would be the same result as long as you can manage to actually assign the read data to qsp variables/arrays etc.

I'm not familiar with javascript. But if it can help deflate the size of the savegame and provide us with additional features I'll learn to use it.

Was the old approach in handling json files the reason why our savegames are so bloated? Pardon me for asking but what exactly is our jack.qsp saving?

 

[Bob9999]

I have a little problem with QSp on win 10. It crush often when I start the game. Is this just me or I can do something about this?

 

[toolkitxx]

I have a little problem with QSp on win 10. It crush often when I start the game. Is this just me or I can do something about this?

Which game are you running with this player? I havnt had any problems at all with the player - could you maybe check your win event log for entries related to this and attach it?

 

[Bob9999]

Game just start properly, I just restart it.

 

[Sonnix]

I have a little problem with QSp on win 10. It crush often when I start the game. Is this just me or I can do something about this?

Which version are you using? 64 or 32 bit? Try using another version and check if there are still problems.
Old versions might have some problems with webengine initialization. I think I fixed that in 1.8.

ps. I was hoping to make an update as new Qt version got released. But for Windows version I also updated visual studio to 2019 and I'm having some problems building Qt with it. After this

You must be registered to see the links

bug gets resolved I will build a new version.

 

[percivalleporidae]

Hi. I have some questions about this player.

1. Should I use version 1.8 (found in the OP) or the one found in

You must be registered to see the links

My device uses Windows 7 32-bit.

2. Will this allow the onerror attribute of the <img> tag? I'd like a conditional to check if an image file exists and if not I'd like the player to show a default image.

Or is there a better way to handle checking for missing images using this player?

3. Per Sonnix's post, I'd like to clarify: does this player require Google Chrome? If so, does it require Chrome to be running or just installed?

With recent changes in how Chrome handles autoplay there might be some problems with autoplay for unmuted videos in Qt 5.12. The most reliable workaround for now is using webm/webp or starting videos with javascript.

4. Should I eliminate usage of image/video files that aren't webm/webp? If no would using other image/video formats pose problems?

5. Are there stability issues that I should be aware of that are in this player but aren't in the classic QSP player?

6. Can you recommend a QSP game that takes full advantage of this player's new features? I'd like to study its .qsp code.

 

[toolkitxx]

Hi. I have some questions about this player.

1. Should I use version 1.8 (found in the OP) or the one found in

You must be registered to see the links

My device uses Windows 7 32-bit.
I believe the 1.8 version here is the most recent one - the ones in the ifwiki are not. Use the 32-bit version from here

2. Will this allow the onerror attribute of the <img> tag? I'd like a conditional to check if an image file exists and if not I'd like the player to show a default image.
Yes it will but it will require you to create some appropriate javascript handling. ONERROR requires an event and since this is not acting on a qsp-event a handler is required.

Or is there a better way to handle checking for missing images using this player?
QSP itself has no functions that allow checking on the harddrive and all Sonnix's player does differently is providing clean html implementation compared to the regular player. QSP originally used a reduced html4 command set, all QSP is still the same. So the only way to achieve what you want is via outside scripting or properly checking your assets

3. Per Sonnix's post, I'd like to clarify: does this player require Google Chrome? If so, does it require Chrome to be running or just installed?
No it doesnt. Sonnix tends to talk like a dev - this is internal stuff how QT handles web things which often means they look at popular web engines used. Since he uses QT as a base for the QSP-player some things also affect how he can implement things in the player


4. Should I eliminate usage of image/video files that aren't webm/webp? If no would using other image/video formats pose problems?
webp and webm will simply use the least space but it is no requirement to use them. Other formats: As long as the images/videos are encoded typically they will show/play

5. Are there stability issues that I should be aware of that are in this player but aren't in the classic QSP player?
Nope

6. Can you recommend a QSP game that takes full advantage of this player's new features? I'd like to study its .qsp code.
I believe you alreaday did

 

[Sonnix]

I think toolkitxx covered everything here.

The version on ifwiki is 1.5 I think. So it's better to use 1.8.

onerror and javascript is supported. As qsp does not have access to filesystem your best bet for checking images would be javascript.

It is based on Chromes engine and acts like Chrome in regard to web standards. But it does not require Chrome or anything else to be installed. I only mention it so that developers would know which web standards are supported.

webm and webp are preferred formats but you don't have to use them. Proprietary codecs such as h264 are also supported. If the video starts and plays for you then it will work on other systems as well. The autoplay problem affected only some videos with problematic encoding. As for images there should be no problems with any of the formats.

As I run into problems I usually mention them here. If there are no problems mentioned in the release notes or in the posts after release then there are no known problems. If you find any bugs report them to me and I will try and fix them.

As for games you can check what toolkitxx is working on https://f95zone.to/threads/saint-petersburg-adventures-v1-02-test-toolkitxx.22717/
And Girl Life was mentioned here but they mostly use it just for videos.
1.6 version of player also included small example showing some of the new features of the player but it is by no means compleat. It was mostly for developers to show how to use some of the features that were most commonly asked about. And it has not been updated in quite some time. Here is the link

You must be registered to see the links

I don't think any game uses all of the features of the player at the moment.

 

[percivalleporidae]

Hi. I have further questions about the player.

1. I can precisely set the colors in the qqsp.ini. How can I do that with the window dimensions? I can set them to some extent by manual manipulation using the mouse. But is there a more precise way to do that?
2. What does geometry in qqsp.ini do?
3. In the Sonnix Qqsp folder, in which file(s) did you define $SETMAINDESCHEAD and $SETSTATHEAD?

EDIT: Ignore #3, I've looked at the source code in GitLab.

EDIT 2: Is there a more efficient way to make old qsp games using HTML 4.01 quirks mode compatible with this player? More efficient that is than rewriting these to the HTML5 standard. Using Mr. Sonnix's player I've tested a few old qsp games coded using the 4.01 quirks mode; the resulting displays are quite wonky or sometimes non-existent.

 

[Sonnix]

Hi. I have further questions about the player.

1. I can precisely set the colors in the qqsp.ini. How can I do that with the window dimensions? I can set them to some extent by manual manipulation using the mouse. But is there a more precise way to do that?
2. What does geometry in qqsp.ini do?
3. In the Sonnix Qqsp folder, in which file(s) did you define $SETMAINDESCHEAD and $SETSTATHEAD?

EDIT: Ignore #3, I've looked at the source code in GitLab.

EDIT 2: Is there a more efficient way to make old qsp games using HTML 4.01 quirks mode compatible with this player? More efficient that is than rewriting these to the HTML5 standard. Using Mr. Sonnix's player I've tested a few old qsp games coded using the 4.01 quirks mode; the resulting displays are quite wonky or sometimes non-existent.

Window dimensions in Qt are a bit complex and not exactly precise.
Dimensions are composed of geometry and windowState. They depend on screen resolution, DPI and physical screen size. They contain information not just about the window but about each individual widget. And all of this is not just numbers but an internal binary representation (and is stored as binary data). geometry state from one user is not guaranteed to look the same on another computer with different screen settings.
Here are the links to the documentation if you are interested:

You must be registered to see the links

You must be registered to see the links

So there is no simple way to set window dimensions right now. And even if you could set them there is no way to restrict resizing the window right now. Classic player did not have a feature like that so I did not implement that.

$SETMAINDESCHEAD and $SETSTATHEAD are set from qsp code and you can check the example in my previous post to see how they are used.

HTML 4.01 quirks were not exactly standard (thank you Internet Explorer 6) and were implemented differently in each browser. So if the game heavily relied on one behavior and did not follow the standard (which is sadly most of the games) there is no simple way to make it work exactly as it did on original player. I've tried to make some workarounds but in the end each game required a new set of workarounds. Maybe some custom css rules might help in simple cases but there is no universal solution.

edit: As an alternative you can try using javascript (something like window.resizeTo()) and css to set content dimensions.

 

[percivalleporidae]

Hi. I have more questions about using this player.

1. Enabling a qsp game to run as quickly as possible

Assuming that I'm using the Sonnix player with all its inherent capabilities and ignoring everything else, in terms of coding what are all the things that I can do to make a qsp game run as quickly as possible?

While lag in text-games isn't noticeable with a powerful enough device, I would like to know how to code a qsp game to still run fast in devices with low specifications.

2. Minimizing the size of qsp saved games

Similar to #1 above, assuming that I'm using the Sonnix player with all its inherent capabilities and ignoring everything else, in terms of coding what are all the things that I can do to minimize the size of qsp saved games?

Again, similar to #1 above, this is for devices with not-so-powerful specifications. In addition, I would like to know the feasibility of autosaves. With large enough saved games coupled with a not-so-powerful device, frequent autosaves can become tedious.

3. HTML4 to HTML5 migration with regards to user interface (UI)

Suppose I'm trying to migrate a game from the classic player to the Sonnix player. Suppose further that I want to make the game's UI in the Sonnix player resemble as closely as possible (if not exactly) its UI in the classic player. Lastly suppose that this game made use of HTML4.01 quirks mode.

Are there special things to consider when migrating from HTML4 to HTML5 when coding in QSP in terms of UI? Or would general non-QSP migration techniques for HTML4 to HTML5 suffice for QSP in terms of UI?

 

[toolkitxx]

Hi. I have more questions about using this player.

1. Enabling a qsp game to run as quickly as possible

Assuming that I'm using the Sonnix player with all its inherent capabilities and ignoring everything else, in terms of coding what are all the things that I can do to make a qsp game run as quickly as possible?

While lag in text-games isn't noticeable with a powerful enough device, I would like to know how to code a qsp game to still run fast in devices with low specifications.

The term 'not so powerful device' leaves a lot of room for interpretation. QSP is pretty old as was the old player. So in terms of speed it oriented itself on devices nearly a decade back - i think that should give you an idea.

2. Minimizing the size of qsp saved games

Similar to #1 above, assuming that I'm using the Sonnix player with all its inherent capabilities and ignoring everything else, in terms of coding what are all the things that I can do to minimize the size of qsp saved games?

Again, similar to #1 above, this is for devices with not-so-powerful specifications. In addition, I would like to know the feasibility of autosaves. With large enough saved games coupled with a not-so-powerful device, frequent autosaves can become tedious.

I checked some of the bigger save games files from 'pure' qsp games and none actually pass 3-4 MB in size - that should definitly not be a problem for any kind of 'device'. The only exception is Jack-o-nine which already uses a modified player (undocumented basically) and those files are nearly triple the size of any others.

3. HTML4 to HTML5 migration with regards to user interface (UI)

Suppose I'm trying to migrate a game from the classic player to the Sonnix player. Suppose further that I want to make the game's UI in the Sonnix player resemble as closely as possible (if not exactly) its UI in the classic player. Lastly suppose that this game made use of HTML4.01 quirks mode.

Are there special things to consider when migrating from HTML4 to HTML5 when coding in QSP in terms of UI? Or would general non-QSP migration techniques for HTML4 to HTML5 suffice for QSP in terms of UI?

Unless the originating game has been made for an already modified player like Jack-o-nine (see Bullet 2) no actual real migration is necessary. All games made for the classic player run without any changes also on Sonnix's player.
So in terms of the UI everything should and will look exactly as before - if it is a regular QSP game.

 

[Sonnix]

Hi. I have more questions about using this player.

1. Enabling a qsp game to run as quickly as possible

Assuming that I'm using the Sonnix player with all its inherent capabilities and ignoring everything else, in terms of coding what are all the things that I can do to make a qsp game run as quickly as possible?

While lag in text-games isn't noticeable with a powerful enough device, I would like to know how to code a qsp game to still run fast in devices with low specifications.

2. Minimizing the size of qsp saved games

Similar to #1 above, assuming that I'm using the Sonnix player with all its inherent capabilities and ignoring everything else, in terms of coding what are all the things that I can do to minimize the size of qsp saved games?

Again, similar to #1 above, this is for devices with not-so-powerful specifications. In addition, I would like to know the feasibility of autosaves. With large enough saved games coupled with a not-so-powerful device, frequent autosaves can become tedious.

3. HTML4 to HTML5 migration with regards to user interface (UI)

Suppose I'm trying to migrate a game from the classic player to the Sonnix player. Suppose further that I want to make the game's UI in the Sonnix player resemble as closely as possible (if not exactly) its UI in the classic player. Lastly suppose that this game made use of HTML4.01 quirks mode.

Are there special things to consider when migrating from HTML4 to HTML5 when coding in QSP in terms of UI? Or would general non-QSP migration techniques for HTML4 to HTML5 suffice for QSP in terms of UI?

qsp can be reasonably fast if you don't abuse loops where they are not needed. Also try to avoid string operations on variables just to display them and never use them again. Displaying multiple variables would be faster then first merging then into one variable.
If you want to use some fancy animations and decorations it's better to use html5 and css then to dynamically generate code with lots of font or color definitions for example.
Apart from that there isn't anything specific to qsp. So just common best coding practices should apply and your code will run fine.

I can confirm that there are no real problems with ~5Mb save files. It all comes down to your hard drive speed. On ssd saves are instant.
Saves are just the collection of all game variables that were ever referenced or initialized during the playtrough. So the only thing I can think of that might help with save size is using KILLVAR when you don't need a variable anymore. At least try to delete all temporary variables and that would help with save size. And try to avoid string variables that contain lots of text. They would probably account for most of the save size if used often.

Porting from html quirks to proper HTML4 would require checking line endings and closing tags. Also you might need to replace a couple of depreciated tags. Porting from proper HTML4 that comply to the standard and has a proper DOCTYPE does not require any changes. It will be displayed properly in any player.
If you need HTML5 features just use them. So just applying common techniques would be enough.
There is nothing special about how QSP treats html code. Any code that complies to one of the html standards would work and display properly.

 

[eorclus]

hi Sonnix, can you give me instruction how to build it from source for linux, or needed dependencies at least?

 

[Sonnix]

hi Sonnix, can you give me instruction how to build it from source for linux, or needed dependencies at least?

As a dependency you only need Qt 5 with qt5-webengine. GStreamer might also be required for sound playback but it should be already installed as a dependency for qt5-multimedia.
Currently minimal supported Qt version is 5.12. For older versions static webengine initialization is broken at the moment. I might look into it when I get to releasing the next version (which should be soon as Qt 5.13.1 is scheduled to be released this week). But in the past (builds with Qt 5.9) dynamic initialization for webengine caused segmentation fault on closing the application so I'm not sure if it is worth fixing.

In the folder with the project file (Qqsp.pro) just call:

qmake

This will generate build files. Then just call:

make

to build the binary.

Currently there is PKGBUILD package build script for Arch Linux:

You must be registered to see the links

All the build steps are there in build() function.

For the next version I will try to update docker build as well so that I can provide a container that works on any distribution.

 

[eorclus]

thx Sonnix, successfully compiled it in linux

 

[percivalleporidae]

Hi Mr. Sonnix. I looked at the source code of Graylor's FastQSP. He was able to add the option to define the sizes of various windows in QSP. Here is the most relevant portion of the source code pertaining to this:

You must be registered to see the links

How can I do the same with your player's source code?

 

[Sonnix]

Hi Mr. Sonnix. I looked at the source code of Graylor's FastQSP. He was able to add the option to define the sizes of various windows in QSP. Here is the most relevant portion of the source code pertaining to this:

You must be registered to see the links

How can I do the same with your player's source code?

The bridge between qsp interpreter and GUI is mostly located in:

You must be registered to see the links

Most of the work with UI is done in:

You must be registered to see the links

First you would have to set some variables for the QSP part (or maybe define it as a function for flexibility). Here is an example of how I did it with SETSTATHEAD for custom HTML headers:

You must be registered to see the links

I would advise making this variables or functions only available when HTML5Extras is enables so that it will not break old games.

Then you would need to pass the values to mainwindow and change the size of the widgets. The widgets you would be looking for are:
QDockWidget* _objectsWidget;
QDockWidget* _actionsWidget;
QDockWidget* _descWidget;
QDockWidget* _inputWidget;
QDockWidget* _mainDescWidget;

To change the size you would need to call resize() method for the widget:

You must be registered to see the links

If you manage to implement that you can send me pull request if you want and I will include it into the player.

 

[Sonnix]

Qt 5.13.1 got released and Visual Studio 2019 got updated. So I was finally able to build the new version.

Version 1.9:
Win64:

You must be registered to see the links

Win32:

You must be registered to see the links

As always I recommend using x64 version where possible.

This version mostly includes some minor internal changes and a bit of work on loading split text files for future version.
The big change is the new Qt version and switch to Visual Studio 2019 from 2017 for Windows version.

I also updated Dockerfile so that a Docker container can be built for Linux. So far this is the easiest possible solution I found for Linux releases. As soon as Qt packages for Arch Linux will be updated I will release the Docker container and post an instruction on how to run it.

I am also trying to make a fresh build for macOS. So far I have so minor problems so it will probably take a couple more days. Xcode does not want to update in macOS 10.13. And VirtualBox does not want to load the system from APFS which is mandatory for 10.14 with default bootloader.

ps. Did I mention how much I hate making Windows builds? It takes forever to build anything using Visual Studio. And when I left Windows 10 on for the night to build Qt it decided to reboot itself and break the build so I had to start over again. And that's on pro version with delayed updates and after I manually checked for any updates before the build.

 

[toolkitxx]

Qt 5.13.1 got released and Visual Studio 2019 got updated. So I was finally able to build the new version.

Version 1.9:
Win64:

You must be registered to see the links

Win32:

You must be registered to see the links

As always I recommend using x64 version where possible.

This version mostly includes some minor internal changes and a bit of work on loading split text files for future version.
The big change is the new Qt version and switch to Visual Studio 2019 from 2017 for Windows version.

I also updated Dockerfile so that a Docker container can be built for Linux. So far this is the easiest possible solution I found for Linux releases. As soon as Qt packages for Arch Linux will be updated I will release the Docker container and post an instruction on how to run it.

I am also trying to make a fresh build for macOS. So far I have so minor problems so it will probably take a couple more days. Xcode does not want to update in macOS 10.13. And VirtualBox does not want to load the system from APFS which is mandatory for 10.14 with default bootloader.

ps. Did I mention how much I hate making Windows builds? It takes forever to build anything using Visual Studio. And when I left Windows 10 on for the night to build Qt it decided to reboot itself and break the build so I had to start over again. And that's on pro version with delayed updates and after I manually checked for any updates before the build.

Updated OP with new version links.

P.S. As for the reboot on WIN - make sure your extended options are set to no for all options in there beside the delayed updates. There is one that actually kind of overrides the delayed update by allowing autonomous reboots.