Erick194

3 hours ago, VGA said:

Is there any framerate improvement with this mod? Is any optimisation possible/planned?

I have tried several times, but it cannot be improved further, the speed of the CPU is not enough, remember that PsxDoom does not render directly in the frame buffer and uses primitives that are sent to the GPU so that the hardware does the drawing in the screen, unlike other ports such as Atari Jaguar or Sega 32x, those that do manipulate the drawing in the frame buffer directly.

Hi, friend. If you mean the lighting effect commonly used in PSX Doom outputs, I believe to date those special lighting effects that the console versions of PSX Doom and Doom64 used have not been implemented in the current GZDoom, in my project the code for these effects is incorporated into the GZDoom 1.9 engine but it is already outdated, in the TC it is very likely that acs was used and you can also consult the CE project that has code adapted from my project in zscript to achieve those effects.

interesting, this is my discord user erick194#0000 in case you want to chat.

2 hours ago, Vita93 said:

It's a hobbyist project.  You've nothing to apologise for.  I love what you've done, it's amazing.

Oh okay, thanks for the support.

2 hours ago, Vita93 said:

Can I ask an awkward question?  I've loved what has been done with this and replayed it on my Vita again-and-again-and-again.

 

It's two years since the last release.  Is there going to be another one?

The truth is that there should be at least one more release, but I haven't focused on that yet, my apologies.

6 hours ago, clayote said:

I'm trying to compile dzdoom on Linux Mint. cmake seemed to work ok, but the actual compilation errors with:

 

/home/sanotehu/src/gzdoom-me-gec-maint1.9/src/p_user.cpp:1900:75: error: ‘TFlags<T, TT>::Self TFlags<T, TT>::operator|(X) const [with X = TFlags<ActorFlag2>; T = ActorFlag; TT = unsigned int; TFlags<T, TT>::Self = TFlags<ActorFlag>]’ is private within this context
 1900 |   !(player->mo->flags & MF_NOGRAVITY | player->mo->flags2 & MF2_FLY))//[GEC]

 

I'm no good at C++. What do I do about this?

Hello friend, at that time I was very new to programming and for some reason the compiler did not give me errors and I know that when compiling in Linux it did reflect errors more than in visual studio.

But the line should be like this:

!(player->mo->flags & MF_NOGRAVITY || player->mo->flags2 & MF2_FLY))//[GEC]

5 hours ago, Klevez said:

Hola. ¿Habrá ingeniería inversa de otros juegos RPG de ID Software (Wolfenstein 3D, Orcs & Elves I & I), o partes exclusivas de Doom (Doom PSX, Doom Ressurection y otros)?

Hello and thanks for commenting. Let me know that I am working on reverse engineering Wolfenstein RPG iOS, Orcs and Elves I & II Brew version and Doom Resurrection iOS and on Psx Doom I have already worked on reverse engineering for the psx hardware and if you want to see a port for PC this PsyDoom by @intacowetrust it's excellent work too.

https://github.com/Erick194/PSXDOOM-RE

https://github.com/BodbDearg/PsyDoom

@sina-gst I have a question, the position of the texts, an example in the main menu, they should look like this

or like this

@sina-gst Ok, an idea occurs to me, I will make a function to invert the numbers that are necessary, and in the drawString function a new flag to write in RTL.

I will be informing you in the next few days of the progress .

5 hours ago, sina-gst said:

You're right @Erick194, it shows 41 in this example, but it should be 14 in the post above. And you're right again, we have a top-bar that shows numbers as well. Any idea? 😭

Hmm, ok I need you to translate some texts from the game and publish them here, so that I can know at your discretion how it should be read, so I can have a main idea and be able to obtain a solution.

Well, repositioning the texts is not the problem here, the problem I see is the numbers, as it should be read correctly in the language you want to add, you mentioned then the amount of health should be 14, but by reversing the order of the text it is 41, how should it be correctly?

@sina-gst Also remember that the top bar shows the texts of the damage received and also uses numbers. 

ok when I was referring to the numbers they would look like this

2 minutes ago, sina-gst said:

You're my hero @Erick194!
Just one question... What's the best version of the Java ones? Are they all the same?

It is almost the same, but in version 1.8.94 it is easier to modify the text

ok don't worry all that can be corrected

Ok although here you also have as a reference the reverse engineering of Doom RPG BREW source code.

Practically it's almost the same.

12 minutes ago, sina-gst said:

Can you send me the version you have @Erick194 please?

Actually, I gave the names of the classes, to be able to identify them more easily, since I also already had this work done previously, but it is not yet complete. I can help you with the modification but I still can't release this reverse engineering of the J2ME version, sorry.

2 minutes ago, sina-gst said:

You mean you RTL'ed the version I'm talking about? 🤯

How did you do that?!

that's the J2ME version

I see, it is because the numbers would also be seen from RTL if the functions are modified.

Hi @sina-gst

Ok, the version you showed me is 1.8.94, that's fine, I can look for the necessary functions to modify them, now my question is the following, according to the language, what do you want to modify the game, how are the numbers handled? It's the same RTL mode

On 1/31/2024 at 1:41 AM, sina-gst said:

I want to translate Doom RPG into Persian (I live in Iran), and I chose the Java ME version.

Since .jar files are like .zip files, I can extract the game file, to see what's inside. So, here's what I got so far:

Ok what version of the game are you using?

Yes, it should be possible, but all the texts must be repositioned.
 

1 hour ago, IttaBaby said:

Is there a way to switch to the java version's sprites?
They look ever so slightly less jank so I prefer them.

Sorry friend but it is not possible, since support for J2ME and BREW versions is not implemented.

@tempun2 Thanks again for informing me of these bugs.

The new version 0.2.2 is available on the OP.

22 hours ago, tempun2 said:

OK. But does the Infernis bug I described above occur there also?

That's it, I remembered and yes the Infernis should not go through the door, in the test executable I sent you I had a line of code misspelled, I noticed shortly after I sent you the executable and I didn't update the one I sent you.

Practically the Infernis is making noclip to the door.

//-----------------------------------------------------------------//
    else if (entity->def->eSubType == 10) {
        i10 &= ~1025; // <- With the error on the line
    }
//-----------------------------------------------------------------//
    else if (entity->def->eSubType == 10) {
        i10 &= ~1024; // <- Without the mistake on the line
    }
//-----------------------------------------------------------------//

And an example regarding the activation sound recorded on the physical device.