Rum and Raisin Doom - Haha software render go BRRRRR! (0.3.1-pre.8 bugfix release - I'm back! FOV sliders ahoy! STILL works with KDiKDiZD!)

[GooberMan]

21 hours ago, marver0PS said:

I don't know if it's been said before, but saves are broken in 0.2.2. The position of things are shifted when you load the game, putting the player and other things outside the map.

 

I had actually noticed this - in a vanilla map I'm working on that includes features which make hardware renderers cry. But I figured it was just something weird I was doing for the map. Thanks for pointing out it's for everything.

The changelist that breaks it is actually the first one I submitted for frame interpolation. Whoops. So that's been broken for a while. I did some testing by switching my branch back and forth between revisions. You can save games just fine in any version, it's the loading that breaks things. And sure enough, that revision includes a modification to the loading code to prime the interpolator with the newly loaded values. Closer look, and yep, I gone and done fucked up. The lines that prime the Y and Z values actually overwrite the original Y and Z values instead of the intended interpolator current values.

 

That's a small lesson in the reasons behind object-oriented programming. In C, you just copy/paste your code everywhere because it's easier. In C++, each interpolator value would be a templated class and a fix in one place would fix it in every invocation in the codebase. Language design makes good programming paradigms possible... and subsequently, the poor language design decisions the standards boards have made in the last 20 years are why I have very strong views against C++ these days. But boy does that language pay the bills for me.

 

Anyway. Fix is going in, and will be released in 0.2.3.

 

EDIT: Now that I fixed that one, there's actually another bug I've noticed. Harmony's melee weapon lower state results in permanently cycling sprite frames from an unrelated actor. I've goofed on Dehacked support somewhere, so might as well track that down now. Will leave the description for the git log on this one when I work it out.

[Xaser]

Stab in the dark since I don't have the DEH open in front of me (yay phone-posting), but DEH tools typically don't output a Next Frame field if it's unchanged from the default, and last time I saw a bug like this (during MBF21 dev) the port in question had the wrong default value for the Next Frame field in a few spots so the intended animation accidentally jumped to some unrelated frame -- dunno if that's the ticket but it's probably worth a look.

[GooberMan]

14 hours ago, Xaser said:

dunno if that's the ticket but it's probably worth a look.

Thanks for the pointer. It at least put me in the right direction, but that was not the cause.

So, the reason I thought I had screwed the pooch on Dehacked support was because I loaded up the Harmony IWAD in Chocolate Doom 3.0.0 and remembered not encountering the issue. Just tested again right then, and yeah it still has the same problem as I'm having. Must have been on a Friday night after I had a few beers or something *shrug*.

 

Anyway. In deh_frame.c there is a lovely comment that says exactly what the problem is, with the DEH_FrameOverflow function being the culprit:

// Simulate a frame overflow: Doom has 967 frames in the states[] array, but
// DOS dehacked internally only allocates memory for 966.  As a result, 
// attempts to set frame 966 (the last frame) will overflow the dehacked
// array and overwrite the weaponinfo[] array instead.
//
// This is noticable in Batman Doom where it is impossible to switch weapons
// away from the fist once selected.

So. This was a Chocolate Doom decision. And honestly it's one that I do find slightly weird in that it replicates the behavior of a third party program and not of the Doom executables themselves. Anything from someone releasing a newer version of Dehacked to a reimplementation of Dehacked (ie not the file format but the binary patching) will nullify that reasoning.

 

Until I think of the best way to handle that particular behavior, it's going behind my currently catch-all remove_limits variable. I have plans on how to handle limit removing overall, and until I implement them it's both a blanket on-switch for every limit removal and an identifier in code as to where work needs to be done.

 

End result: Harmony's weapon switching works. And since you need to -removelimits anyway for the wide screen assets, nothing else needs to be done but make another release for anyone running Harmony.

Edited October 25, 2022 by GooberMan

[GooberMan]

https://github.com/GooberMan/rum-and-raisin-doom/releases/tag/rum-and-raisin-doom-0.2.3

 

So, what else is new? Well how about the load balancer finally working correctly, prompting the number of running threads to be a fully supported (and thus saves to the config file) option?

 

 

Oh and also vsync I guess. Turns out the GL swap interval functions actually do work as expected, so I'm able to set all sorts of vsync rates. Note that I will never expose refresh rates <35Hz in this menu for the obvious reason of Doom's update logic running at 35Hz and thus you're gonna get input lag like a bitch.

 

I don't actually have a desktop with a VRR capable card in it, but I did actually program support for it. Untested of course. My TV supports both G-Sync and FreeSync, just lacking the PC side of the hardware.

[GooberMan]

I'm working on a few things for a full 0.3.0 release. Just dropping a couple of screenshots.

Someone might like what I did to the resolution menu:

 

And as you might notice, there's 32:9 backbuffer sizes in there. I don't know why I had it in my brain that 32:9 wasn't working with my renderer, but it works just kromulently.

 

It's almost like cheating seeing this much of the level at once.

[kaleb.]

for some reason i cant use this port for more than just 1 minute before this error happens.

also yes i am using 0.2.3 but the titlebar still says 0.2.2 for some reason

[GooberMan]

That bug (and the incorrect version string) is fixed in the upcoming 0.3.0 release. I changed around the load balancer slightly, and put a fallback in to just plain reset all render contexts to even screen coverage if it hits that error.

 

You can reduce the number of render contexts in the "Screen" tab in the options window; or run -numrendercontexts 1 on the command line for the time being.

[GooberMan]

THE 0.3.0 release is here!

https://github.com/GooberMan/rum-and-raisin-doom/releases/tag/rum-and-raisin-doom-0.3.0

This is a hefty chonker of a release, so let's start simple before getting to the one that'll take the most screenshots to show off.

Dynamic resolution scaling

 

For when FPS is the most important thing.

 

This feature is in an early stage of functionality. But it's working. When the frame budget (currently excluding operating system shenanigans) exceeds a certain threshold for your vsync settings, we now scale down the amount of pixels rendered. It currently affects horizontal and vertical scales, in the future you'll be able to independently select which axes you want to scale. You'll also notice that the status bar looks weird as it flickers between DRS scales. I'm going to change how I handle that thing in the very near future. It was already an expensive chonker since I re-render it every frame. I'll go back to selective rendering (will cache the back panel on resolution change) - and render it in its original resolution. Going to be easier than trying to get the integer scaling right.

 

Stats overlay

It looks a bit spartan right now. But I've programmed an extensible way of defining displayable stats in to the code. There will be an editor for the stats overlay in the near future. But for now, at least there's some stats. I also render it using Dear ImGui instead of writing directly to the software backbuffer. It'll look nicer in the future.

UMAPINFO and DMAPINFO support



I decided to do this before I knew KDiKDiZD was dropping. Good timing. And then it exposed many bugs in the UMAPINFO implementation. I've got a rant about that format (I have to redefine intermissions for every map? Really). But the important bit for users is that it's there and it works.

 

The only thing actually missing from it is generating map name graphics. Because I haven't solved how I want to do bigfonts yet. Everything else works - intermissions, boss actions, you name it. If it doesn't, please report it as a bug.

 

Launcher frontend!

 

Pretending I'm correct because I'm bad at sandboxing application and library behavior isn't my style. So I set out to make a launcher frontend for Rum and Raisin. I have some fairly clear goals for it, and I've got a good chunk of them done in this initial release.

 

First up - the behavior. If you specify an -iwad on the command line, it entirely skips the launcher. But you can invoke it anyway by adding -launcher on the command line. There's also some extra behavior hidden in there. If you specify -launcher <path to application here> Rum and Raisin will launch that program and wait for the results.

 

How does it get those results?

 

Well. Rather than inventing Yet Another Fucking Way Of Doing Something, I decided to lean on 50+ years of computing history and use pipes. Running your Doom port of choice with a launcher by going launcher_app | doom_port is something that should work. And I know that years of Windows programming means no launcher probably works like that, but I'm supporting it anyway. Make your launcher print to stdout then quit and I'll read from it. It's reverse piping like that, sure, but importantly that's the only work you need to do to make the standard piping execution behavior work with Rum and Raisin Doom.

This approach permeates my entire approach to the launcher. The internal launcher returns a string of new command line parameters. The same code to push those parameters in to the normal list is then run regardless of what launcher you use. Leaves me room to write a DLL API if I so choose, so anyone can write a launcher that slots right in. But for now, let's get on with the actual launcher behavior.

 

First things first, you'll want IWADs. But what if you have none?

 

Yep. Pick your IWADs, and if it's Doom shareware or HacX pick your /idgames location to download from. Freedoom downloads from Github, so you won't get that popup. Once you've got an IWAD, a "Continue" button pops up and then you can be on your merry.

Let's talk about the Shareware IWAD though. Because uploading the .WAD by itself is a violation of the shareware release's "distribute without modification" clause. And Bethesda doesn't like you violating its clauses. Wat do? Well, the following:

1. Download the shareware zip
2. Extract the shareware zip
3. Look for a .DAT file to ensure you've got a ye-olde DeICE installer package
4. Recombine the .1/.2/.etc files in to one to make a valid DOS-executable self-extracting zip
5. Strip the zip file from the executable in to a separate file (actually an unnecessary step)
6. Extract that zip somewhere
7. Now you have a DOOM1.WAD ready to use

I've written ZIP handlers before, but that was in 2010. I totally forgot that the table of contents being at the end of the file means you don't even need to do step 6. Any unzipper code can handle it from there. This didn't click until after I'd written a DOS executable header reader, extracted the contents from the data segment, and patched up the table of contents' sizes to exclude the original executable data. Oh well. At least it's a ZIP that has no chance of running as code once I'm done with it.

 

I will look in to splitting that code in to a separate Github repository and making a utility out of it. I'm sure it'll come in handy for anyone trying to get data from original disks without resorting to DOSBox to run a full install.

Anyway. Once you're continuing it's on to the next step.

 

Rum and Raisin searches every valid IWAD folder for files, recursively. It'll get WADs and DEHs, sort them, and bring you to the next screen.

The main interface. The scroller at the top lets you choose the IWAD. It identifies Original, BFG Edition, and Unity port IWADs and tells you all about it.

Those startup options are fairly self explanatory, so I won't go in to them. But what if you want to add some PWADs?

 

This screen lets you add and remove PWADs and DEHs from the file parameters list. It currently only handles those that have been picked up with the scanner - future work will include specifying PWAD paths etc. But for now, you can manage the selected files as much as you want.

But say you're a brand new Doom sourceport player, or are bored one day. You want more WADs. What about an integrated idgames browser?

 

 

 

 

The downloading works just like in the IWAD screen. And once it's downloaded, if the included WADs have a Titlepic you'll see the titlepic. Nice. Clicking "select for play" overwrites the previously-illustrated selected files, so you won't get accidental conflicts by loading Doom 2 In Spain Only on top of Knee-Deep in Knee-Deep in ZDoom.

And then you're in to the game. I guess it looks like Freedoom works as intended, as Doom 2 In Spain Only illustrates here:


 

[Turin Turambar]

Great job!

 

Although it seems strange how far you went to offer a way to download the shareware wad, the integration to download custom wads the id archive, etc, but you haven't put a simple browse files from computer dialog to let users pick their own doom2.wad.

 

What's 'threshold' in the mouse options? (and more than explaining it here, it should be in a mouseover hint)

 

Speaking of mouse, I'm going to sound like a heretic for the purists, but I prefer to play Doom with more modern controls. This is, with vertical mouse movement and no autoaim. Any chance to be in your future roadmap?

[GooberMan]

11 hours ago, Turin Turambar said:

vertical mouse movement and no autoaim. Any chance to be in your future roadmap?

Eventually, yes. Still some things to do before I give Rum and Raisin the full 6DoF.

 

11 hours ago, Turin Turambar said:

What's 'threshold' in the mouse options?

Looks like a Chocolate Doom options, most of them I haven't touched since I implemented the options panel and ditched the setup executable. I'll look in to condensing this in to a tooltip.

 

11 hours ago, Turin Turambar said:

Although it seems strange how far you went to offer a way to download the shareware wad, the integration to download custom wads the id archive, etc, but you haven't put a simple browse files from computer dialog to let users pick their own doom2.wad.

 

I've got a two part comment on this one.

The first part: Implementing the browse files dialogue with Dear ImGui (the UI framework used for the dashboard) is not as simple as it seems. It doesn't come with a file browser, so you have to write your own. It's not a hard task, will probably take me one evening to knock it out. But it is one that I decided to put to the side for a few reasons. Still, the intent of your comment is probably right and I should have just done it before uploading 0.3.0.

 

The second part: The focus on this release was for the first time Doom source port user with a particular focus on Raspberry Pi. The addition of the launcher adds the final piece of the puzzle for a fresh install. If you run the port with a fresh install, you'll see that the flow goes "Introduction -> Options -> Launcher". The flow being defined is important for addressing that user base.

 

As such, it means I didn't focus on other areas that need some attention. IWAD resolution is actually one of those things. IWADs are currently detected using Chocolate Doom logic - the folder the port is running from, followed by common install locations (including looking up your Steam install folder). On Linux, that also includes ~/.local/share, /usr/share/games/doom, and a few other variants. This part of the functionality won't change in the future, and in fact I'll probably look at adding GoG install paths to the lookups.

Letting the user specify another IWAD path though, well, that requires another infrastructure change. Namely, the .cfg file. Chocolate Doom's config system is entirely compatible with vanilla. And I hit the limits of what that could do for me some time ago (take a look at how custom automap colours are defined). I think it's time I ditched that functionality. And thanks to doing the idgames browser, I now have a critical piece of the new way of doing things: a JSON handler. With that, I'll be able to have a configuration file that lets you specify as many IWAD and PWAD lookup folders as you want among other things (being structured means the automap colours will look way better in the configuration file, as well as opening the possibility of having multiple custom automap colour sets - probably necessary given how many mapsets change the palette these days).

 

I also have some thinking to do on how to solve downloading commercial IWADs in a legal manner for those first time users. But at a minimum, the Download More Maps panel will include functionality for a user to specify a download URL and let Rum and Raisin take care of the rest. I also realised once I got the screenshot displaying in the actual mapset panel that having a WAD manager that doesn't continually read from idgames for the folder layout would be best, so there's a bit of refactoring for that before I'm happy with the local WAD browser.

[Floowand]

Has anyone had any luck compiling on linux?

I was following the chocolate-doom instructions but it shows an error and using generic cmake instructions doesn't work either

[GooberMan]

Which distro? I've only compiled on Debian-based distros. If you're following the Chocolate Doom wiki, you'll need to follow the "Tracking Git" section's instructions. No idea if that will work on other distros. The cmake files are leftovers from Chocolate Doom that I haven't cleaned up yet, so ignore them.

If the error is dependencies, I'll probably have to make a complete package list that you should install as I've found what comes pre-installed differs between distros. Ubuntu 20 and later even changed how Python is installed, required the python_is_python_3 package to be installed. Apart from Clang, installing the Linux equivalent of the required Windows packages will just about get you there.

 

 

[Floowand]

33 minutes ago, GooberMan said:

Which distro? I've only compiled on Debian-based distros. If you're following the Chocolate Doom wiki, you'll need to follow the "Tracking Git" section's instructions. No idea if that will work on other distros. The cmake files are leftovers from Chocolate Doom that I haven't cleaned up yet, so ignore them.

If the error is dependencies, I'll probably have to make a complete package list that you should install as I've found what comes pre-installed differs between distros. Ubuntu 20 and later even changed how Python is installed, required the python_is_python_3 package to be installed. Apart from Clang, installing the Linux equivalent of the required Windows packages will just about get you there.

 

 

MX Linux (Debian 11)

This is what the terminal show when using the ./autogen.sh

Spoiler

src/Makefile.am:60: warning: source file '$(top_builddir)/ext/glad/src/glad.c' is in a subdirectory,
src/Makefile.am:60: but option 'subdir-objects' is disabled
automake: warning: possible forward-incompatibility.
automake: At least a source file is in a subdirectory, but the 'subdir-objects'
automake: automake option hasn't been enabled.  For now, the corresponding output
automake: object file(s) will be placed in the top-level directory.  However,
automake: this behaviour will change in future Automake versions: they will
automake: unconditionally cause object files to be placed in the same subdirectory
automake: of the corresponding sources.
automake: You are advised to start using 'subdir-objects' option throughout your
automake: project, to avoid future incompatibilities.
src/Makefile.am:60: warning: source file '$(top_builddir)/ext/cimgui/imgui/imgui.cpp' is in a subdirectory,
src/Makefile.am:60: but option 'subdir-objects' is disabled
src/Makefile.am:60: warning: source file '$(top_builddir)/ext/cimgui/imgui/imgui_demo.cpp' is in a subdirectory,
src/Makefile.am:60: but option 'subdir-objects' is disabled
src/Makefile.am:60: warning: source file '$(top_builddir)/ext/cimgui/imgui/imgui_draw.cpp' is in a subdirectory,
src/Makefile.am:60: but option 'subdir-objects' is disabled
src/Makefile.am:60: warning: source file '$(top_builddir)/ext/cimgui/imgui/imgui_tables.cpp' is in a subdirectory,
src/Makefile.am:60: but option 'subdir-objects' is disabled
src/Makefile.am:60: warning: source file '$(top_builddir)/ext/cimgui/imgui/imgui_widgets.cpp' is in a subdirectory,
src/Makefile.am:60: but option 'subdir-objects' is disabled
src/Makefile.am:60: warning: source file '$(top_builddir)/ext/cimgui/imgui/backends/imgui_impl_opengl3.cpp' is in a subdirectory,
src/Makefile.am:60: but option 'subdir-objects' is disabled
src/Makefile.am:60: warning: source file '$(top_builddir)/ext/cimgui/imgui/backends/imgui_impl_sdl.cpp' is in a subdirectory,
src/Makefile.am:60: but option 'subdir-objects' is disabled
src/Makefile.am:60: warning: source file '$(top_builddir)/ext/cimgui/cimgui.cpp' is in a subdirectory,
src/Makefile.am:60: but option 'subdir-objects' is disabled
src/Makefile.am:60: warning: source file '$(top_builddir)/ext/cimguiglue/cimguiglue.cpp' is in a subdirectory,
src/Makefile.am:60: but option 'subdir-objects' is disabled
src/Makefile.am:55: warning: variable '@PROGRAM_PREFIX@server_SOURCES' is defined but no program or
src/Makefile.am:55: library has '@PROGRAM_PREFIX@server' as canonical name (possible typo)
src/Makefile.am:56: warning: variable '@PROGRAM_PREFIX@server_LDADD' is defined but no program or
src/Makefile.am:56: library has '@PROGRAM_PREFIX@server' as canonical name (possible typo)
checking build system type... x86_64-pc-linux-gnu
checking host system type... x86_64-pc-linux-gnu
checking for gcc... clang
checking whether the C compiler works... no
configure: error: in `/home/xxxx/rum-and-raisin-doom':
configure: error: C compiler cannot create executables
See `config.log' for more details

 

[GooberMan]

3 minutes ago, Floowand said:

checking whether the C compiler works... no

 

That is quite unusual. Might need to apt install build-essential to get that going according to a quick Google.

[Floowand]

Well I'm an idiot, I forgot to install clang, but after I did and finally ./autogen.sh working, the terminal shows this at the end after using make.

Spoiler

In file included from m_menu.c:73:
../../ext/cimguiglue/cimguiglue.h:28:10: fatal error: 'cimgui.h' file not found
#include "cimgui.h"
         ^~~~~~~~~~
1 error generated.
make[2]: *** [Makefile:588: m_menu.o] Error 1
make[2]: se sale del directorio '/home/xxxx/rum-and-raisin-doom/src/doom'
make[1]: *** [Makefile:1144: install-recursive] Error 1
make[1]: se sale del directorio '/home/xxxx/rum-and-raisin-doom/src'
make: *** [Makefile:501: install-recursive] Error 1

 

[indigotyrian]

Having an integrated WAD selector and downloader is huge! This is something I really think more source ports should have, so it's exciting to see it here.

[Turin Turambar]

So... what are your future plans regarding map support? IE. Boom, etc.

 

Given that the main appeal of this sourceport is (imo) the MT performance, it's kind a pity it can't be used in something like Sunder.

[GooberMan]

10 hours ago, Floowand said:

In file included from m_menu.c:73:
../../ext/cimguiglue/cimguiglue.h:28:10: fatal error: 'cimgui.h' file not found
#include "cimgui.h"
         ^~~~~~~~~~

Not finding cimgui would mean that you need to do a git submodule update --init --recursive to pull in both cimgui and imgui itself.

 

5 hours ago, Turin Turambar said:

So... what are your future plans regarding map support? IE. Boom, etc.

 

Given that the main appeal of this sourceport is (imo) the MT performance, it's kind a pity it can't be used in something like Sunder.

Boom, MBF, and MBF21 are planned. It's a common response for the features that I have planned, but there is some groundwork that needs to be done before I get started on that.

Good news though is that I have enough features already to load Sunder maps.

 

Playing is out of the question right now just for the blockmap alone.

[Floowand]

After searching and trying in different ways I could never get it to work on MX Linux, I tried on linux mint and it compiled without problems and I managed to get it running, but when I try to run it a second time it closes during the "updating wad dictionary".

[GooberMan]

ConSigNo had a crash in the same place earlier, gave me a GDB callstack indicating there's a crash in the TITLEPIC texture extraction/loading. Not sure what WAD triggers it yet, but knowing the cause means there'll certainly be a fix coming soon.

 

I'll also do a 0.3.1 release within the next week, including bug fixes and the file browser dialog (currently in a fairly ghetto state, and you can't select another drive on Windows yet because the C++ standards board didn't think std:: filesystem needed such frivolities so I need to do some platform specific special code to handle all that).

[viti95]

Insane work @GooberMan !! Latest git tested on Manjaro (Arch based linux) and runs insanely good. This is rendering at max 16:9 backbuffer resolution (4266x2000) on an Xeon E3-1245v2 (basically an i7 4770 with 100MHz less) with a 2Gb Geforce 750 Ti.

 

The only issue i've found is that is very easy to hide ImGUI panels and not be able to bring them back. You can see the windows in the lower right corner of the screenshot. Also still waiting for the keyboard movement fix, left and right steering still feels choppy.

 

 

Edit: Video of the ImGUI windows issue

 

 

Edited November 22, 2022 by viti95

[Codename_Delta]

Oh shit, when I get home, I'm trying this out, would love to see a version that supports all of the boom shit, might replace choco for me too, since it's still fully vanilla, I've had some ideas myself for a port like this, but I lack any of the coding experience :P.

 

(It was gonna be called Mint-Chocolate Chip Doom [my favourite flavour of ice cream])

 

 

[GooberMan]

3 hours ago, viti95 said:

Video of the ImGUI windows issue

 

Ah bloody hell. GitHub latest has a new version of ImGui, and it's one bug after another at the moment. Raspberry Pi doesn't launch because ImGui gets the GL version number wrong. And that bug with slow moving windows not matching the mouse cursor came about because ImGui suddenly relied on the SDL logical screen size. Must have missed a case there, it looks like it's still using a smaller window's coordinates. Will get on it.

[Codename_Delta]

tried runnin it and I keep on getting a bad v_draw patch.

 

idk why

[GooberMan]

34 minutes ago, Codename_Delta said:

tried runnin it and I keep on getting a bad v_draw patch.

Sounds like the TITLEPIC thing I mentioned previously. If you're running on Linux, I print the WAD it's trying to parse to the terminal. If you're running Windows, I only print to debug output unfortunately.

 

1 hour ago, GooberMan said:

Must have missed a case there, it looks like it's still using a smaller window's coordinates. Will get on it.

Yeah, turns out that I was using the software backbuffer resolution when I shouldn't have. Fix has been pushed, should be all good now.

[viti95]

5 minutes ago, GooberMan said:

Yeah, turns out that I was using the software backbuffer resolution when I shouldn't have. Fix has been pushed, should be all good now. 

 

Tested and indeed is fixed, great!

[Codename_Delta]

21 minutes ago, GooberMan said:

I only print to debug output unfortunately

damn

[GooberMan]

I changed the TITLEPIC code over to use something more like the texture composite generator than calling the patch renderer. Since this should fix the problem, I've pushed out a quick Windows-only binary release. This should work better for anyone getting the problem.

There's also a bunch of other bug fixes and other little things included in it. The only real quality-of-life improvement though? I use Boom key icons in the HUD if they exist in limit-removing mode.

 

Full notes and features added will come with the full 0.3.1 release.

[Codename_Delta]

also, is it meant to just close when I try to get past the setup?

 

but the v_draw shit is fixed

Edited November 22, 2022 by Codename_Delta

[GooberMan]

The only thing I can think of that would cause a quit like that is if multiple threads are throwing an error. Launch Rum and Raisin with the -options parameter, go in to the Screen tab, and set Running Threads to 1. That will at least keep the message box up to let you know what's going on.

(And it looks to be about time I addressed that error handler, it's another thing that hasn't changed from Chocolate)