Plombo's to-do list

I was really thinking about that, because in light of the Android port. When I updated the libraries, I used 2.0.2 which was the final one to support Android 2.2.5. Since there's not much any difference in SDL 2.0 and 2.0.2, I wouldn't be much worried. What I was concerned was if you used a more recent SDL like 2.0.3, which otherwise break compatibility to old hardware, so yeah, glad that you used the older ones.

This also means that the toolchain that we currently used would be updated, right?
 
Made a ton of WebM progress today.  As I very well should have, since I spent a solid 6 hours working on it.

The big thing I accomplished is reworking the audio code so that it will work with OpenBOR's sound mixer.  Audio decoding is now done in a separate thread from audio output.  I also worked on a couple of smaller things, like properly cleaning up after the video is done playing.  Hopefully after the next day like this, the code will be ready for merging into OpenBOR. :)
 
I think that's because drawsprite just draws the sprite directly to the global screen regardless of if you have a local screen.

The local screen is defined or allocated with allocscreen. This would be independently drawn of the global screen. You can use this for effects and such.

drawspritetoscreen on the other hand uses a local screen, so a sprite drawn on a local screen is different than the screen globally used by the engine.

See the Manual on allocscreen and free (for freeing up the allocated screen).

I guess that's how I interpret that.
 
Today I fixed something that had been bugging me for a while.  Anyone who uses the Wii port a lot will know that it's always had a problem with sound.  This is because the Wii hardware requires sound output to be at 48000 Hz, and most music and SFX in OpenBOR games are at 44100 Hz, so OpenBOR has to upsample it, and the result sounds like it's been filtered through a crappy speaker.

There's a component in libogc (core library used in Wii homebrew development) called asndlib, which is an alternative to the raw audio interface that OpenBOR's Wii port has historically used. Along with a handful of features that we don't need, it can use the Wii's built-in DSP hardware to do high-quality sample rate conversion.  You can see where this is going - I've taken some permissively licensed open source code using asndlib and retooled it into a new audio backend for OpenBOR on the Wii.  And sure enough, the sound is much better now! :)

TL;DR: The audio on the Wii will stop sucking in the next release.
 
Remember the GUI for alpha mask generation?  I restarted that project today.  Here's the first screenshot of SpriteBuddy:

YkMaRam.png


As you might be able to tell from that screenshot, it's not just for creating alpha masks - it's also a complete replacement for PalApply. :)
 
Great, I cant imagine how i could live without palapply, now it speeds up my workflow A LOT, i copy pasted frames one by one to paint but now i just batch convert in palapply and its done  :)
I dont know anyone who tried to use alphamask on sprites and backgrounds in their mods, probably because all sprites are from snes ,90's era and its mostly new games that use this feature like rayman which has png sheet with bodyparts on transparent background, for alternate remaps its using separate recolored png's.
It looks and blends really nice with colorful backgrounds

http://i455.photobucket.com/albums/qq271/Fuurio/RAYMANORIGINSEXE_0x58DC50B1_zps029e34a9.png~original

https://www.youtube.com/watch?v=y-chi097uV4
Great video about their engine , i like how you can just drag/extrude ground around and create backgrounds in seconds :)
 
Added a few things to the list:
  • Fix SDL joystick support.
  • Improve WebM playback, i.e., implement A/V sync in a less crude way.
  • Look into supporting some form of arrays in script.
Click to expand...

Also of note is that smealum is apparently releasing Ninjhax 2.0 in the coming weeks.  When he does, I should be able to revive the 3DS port.  I'll probably end up rewriting most of it from scratch, though.  The previous iteration added an ugly mess of #ifdefs to the file I/O code (since the standard I/O functions didn't work in ctrulib) and a hacked-together video backend that didn't use the GPU at all, not to mention the audio code that I never got working.  Hopefully ctrulib has matured in the 7-8 months since 3DS homebrew became accessible to the masses, and those things will turn out nicely this time.

Of course, you'll still need Cubic Ninja to run it, at least until someone comes up with an exploit for another game.  It's not a problem for me, since I moved fast and got a copy for $5 in November of last year, but nowadays it goes for around $50 on the US Amazon Marketplace. :o

Oh, and for anyone worried that this will go the way of the last 3DS port (where I updated my 3DS system software because I wanted to access the eShop again), never fear.  I have two 3DSes now, so once Ninjhax 2.0 comes out, I can use the old one as a homebrew machine while continuing to play commercial games on my main one. :)
 
Plombo said:
... I moved fast and got a copy for $5 in November of last year, but nowadays it goes for around $50 on the US Amazon Marketplace. :o
Click to expand...

That's what happen when people found out that you could use the game for homebrew at the same time becoming a collector's item.

BTW, nice proposition so far. I hope you could get the 3DS port to work again, hoping for the maturity of their graphics lib though.
 
BeasTie said:
...
Click to expand...

Worth it probably if you could buy their product. This goes in conjunction with their products that you need to buy. The runtimes are not open source (even if their sources are in GitHub).

The code could only be used for personal and internal use, if you have bought a license from Esoteric:

You are granted a perpetual, non-exclusive, non-sublicensable and
non-transferable license to use, install, execute and perform the Spine
Runtimes Software (the "Software") and derivative works solely for personal
or internal use.
Click to expand...

You can read their license in it's entirety here, but basically, it says the thing above on their paid versions ("If the Spine Essential, Professional, Enterprise, or Education license is selected from Exhibit A ...") and not their trial version.

I was hoping they would make it open source though, but if people would want a feature like this that is open source, you may want to look some place else.



Besides this type of graphics, there are other things we could use true transparency images for.
Click to expand...

The other one OTOH is something to look for, I would say
 
Oh, I thought you were talking a suggestion to Plombo, but yeah, the runtime still is not open source.

You could use the program to make sprites on, but I'm still looking at alternatives to it's runtime that are open source and permissive for our engine, but so far, I see no results.

But I get what Plombo's confused about, IK is not a priority.
 
Made more progress on SpriteBuddy yesterday and today.  The conversion backend is fully working now, and the GUI is also in decent shape.  I'm hopeful that it will be ready for a preview release after one or two more days of solid progress. :)
 
I found problem in palapply with gif palette file which is trivial but it stops palapply from working , if gif in palette.gif is in caps ( palette.GIF then palapply doesnt convert .checked many times and i confirm its the cause and some programs automatcally give extensions in caps.for a lot of newfomers tha could be big problem cause i remember it was for me and i thought palapply doesnt work with random files cause it didnt convert and i didnt know what was the cause.
 
You must log in or register to reply here.
Back
Top Bottom