Conversation

Notices

1. steve (steve02081504@ukadon.shillest.net)'s status on Wednesday, 17-Jan-2024 10:10:45 JST steve

   • ぽな (C.Ponapalt)

   @ponapalt
   Just a rough idea, is it possible to get ghost to allow some manipulation of the image in the final shell render, like non-geometric stretching and shrinking or something?
   I was just thinking about ssp when I was suggesting some games, and sometimes it's not practical to do multiple boob splits for dozens of shells in order to allow ghost to have optional boob sizes, so why not just morph the boob part of the final image?
   (This was just a spur-of-the-moment suggestion! It doesn't appeal to me at all as much as the animation script for the icons so it's not a necessity for me)

   • ぽな (C.Ponapalt) (ponapalt@ukadon.shillest.net)'s status on Wednesday, 17-Jan-2024 10:10:45 JST ぽな (C.Ponapalt)

     in reply to

     @steve02081504 In the past, we had an idea in another environment called CROW to add a DLL that would apply a filter to the shell rendering results.
     It would be a DLL that would input and output bitmaps with transparency.
     Unfortunately, the specifications for this have been lost, but if you are interested, I would like you to come up with some appropriate specifications.
     If the specifications also pass the current surface number and animation number, it could serve as a starting point for realizing a specification that completely overrides the rendering results of SSP.

   • ぽな (C.Ponapalt) (ponapalt@ukadon.shillest.net)'s status on Wednesday, 17-Jan-2024 10:16:29 JST ぽな (C.Ponapalt)

     in reply to

     @steve02081504 The specification would probably be in the form of a HANDLE of the DIB being passed from the SSP and exporting a function to process and return the contents without changing the size.
     Currently, the only DIB used inside SSP is 32-bit DIB in translucent use mode. I think it is a good specification that the old compatibility, region mode, is not considered.

   • steve (steve02081504@ukadon.shillest.net)'s status on Wednesday, 17-Jan-2024 10:28:56 JST steve

     in reply to

     • ぽな (C.Ponapalt)

     @ponapalt If possible I'd like to like shioris, further split the existing logic of how ssp reads shell images and renders the shell as a dll file, so that the new ghost can perhaps just ditch the old shell organisation in favour of 3D models or live2d. For old compatibility, ssp will default to using the This split outed provider dll if the shell doesn't specify one.
     The dll file can call the dll file so no matter there is no problem how many layers of extra processing are added!
     And given that the splitting process will inevitably lead to conclusions about all the currently predictable conditions, this customised shell rendering provider specification will be the best fit.

   • ぽな (C.Ponapalt) (ponapalt@ukadon.shillest.net)'s status on Wednesday, 17-Jan-2024 11:13:06 JST ぽな (C.Ponapalt)

     in reply to

     @steve02081504 I have moved the topic too far ahead. My apologies.
     Thinking too far ahead will hinder progress, so let's first decide on the specifications for the effects/transform DLLs, which is the current issue, and consider separating SERIKO's specifications later.

   • steve (steve02081504@ukadon.shillest.net)'s status on Wednesday, 17-Jan-2024 13:21:58 JST steve

     in reply to

     • ぽな (C.Ponapalt)

     @ponapalt As far as my current knowledge goes just have the following:
     1. image input and image output
     2. allow shiori to read and set data via sakura scripts
     3. maybe allow the dll to provide certain messages in each message to shiori.