[RGD] DirectX implementation of RGSS3

Discussion in 'Useful Development Tools' started by invwindy, May 13, 2018.

  1. Valentine90

    Valentine90 Veteran Veteran

    Messages:
    36
    Likes Received:
    12
    Location:
    Brazil
    First Language:
    Português
    Primarily Uses:
    RMVXA
    I made a small correction in the compression of the text. It does not solve the problem fully, but it improves a bit.
    Code:
      class Bitmap
        alias vxaos_draw_text draw_text
        def draw_text(*args)
          args[2] += 20 unless args[5] || args[0].is_a?(Rect)
          vxaos_draw_text(*args)
        end
      end
     
  2. Sixth

    Sixth Veteran Veteran

    Messages:
    2,130
    Likes Received:
    798
    First Language:
    Hungarian
    Primarily Uses:
    RMVXA
    @Valentine90
    From what I see, you just added 20 to the width argument. Why don't you do that where you use the draw_text method directly?
    I don't get any false text compression bug, at least I haven't noticed any so far.

    @invwindy
    I get a crash if I try to change the scale ratio when the game is in fullscreen mode.
     
  3. Valentine90

    Valentine90 Veteran Veteran

    Messages:
    36
    Likes Received:
    12
    Location:
    Brazil
    First Language:
    Português
    Primarily Uses:
    RMVXA
    @Sixth
    I use draw_text more than 50 times in my project. And this gives trouble even with texts that are in the middle. Generally, if I want to put text in the center, I just need to pass the contents.width width, but this does not work anymore since the RGD started to have text compressor. Text compressor is totally unnecessary, should be removed, there is no reason for a text to be squeezed. You probably only tested with English, but this compressor gets very bad with Portuguese.
     
  4. Sixth

    Sixth Veteran Veteran

    Messages:
    2,130
    Likes Received:
    798
    First Language:
    Hungarian
    Primarily Uses:
    RMVXA
    I don't see any reason to differentiate between English and Portuguese, they both use latin characters. Chinese, Japanese, Korean, and such, sure, they use different characters, but Portuguese is the same as English in this regard.

    I haven't used it much on window objects though, only on sprites, maybe that's why I haven't noticed any of these compression issues you mentioned.
    And you mentioned that you use contents.width, so maybe there's an issue of calculating that, and not an issue with the text compression itself. Just guessing here, but it is possible. Should be simple to test it as well.

    I always disliked these text compression things in games as well, but some people may like it, so instead of removing it, making it optional with a simple flag variable would be better, I guess.
     
  5. gstv87

    gstv87 Veteran Veteran

    Messages:
    1,769
    Likes Received:
    798
    First Language:
    Spanish
    Primarily Uses:
    RMVXA
    @Valentine90
    that patch is not for solving a problem with fonts, or drawing methods, or languages.
    that fix only accounts for width parameters (manually-specified width parameters) that don't correlate with the size of the string being used.

    you can just use
    Code:
    draw_text(text_size(str), str)
    
    and it'll self-correct accordingly.

    granted, the width parameter doesn't always fit correctly, but that's due to other factors such as extra pixels being accounted for shadows, outlines or italic text.
    text_size(str) will always give you the rect you need, regardless of font type (->font, inherited from language)

    if the *label* you intend to display doesn't fit the *space* you've assigned that *label* to display *within*, then your problem is interface design, not font drawing..... you just ran out of space to draw on.
     
  6. Valentine90

    Valentine90 Veteran Veteran

    Messages:
    36
    Likes Received:
    12
    Location:
    Brazil
    First Language:
    Português
    Primarily Uses:
    RMVXA
    Default (Game.exe original):
    [​IMG]
    RGD:
    [​IMG]
    All the texts in my project were messed up, they were not messed up in the original Game.exe and I did not understand the logic used in the current RGD to fix this. I repeat: text compression is just a bad idea of the original Game.exe that should not be repeated. There is no reason for the text to get squeezed if it is not fitting in the window.

    @gstv87
    That would be a simple but bad solution. The "text_size" is a bit heavy, it would be very bad to use this in all texts, especially those that are constantly redesigned in the "def refresh" due to some change in the window.
     
  7. gstv87

    gstv87 Veteran Veteran

    Messages:
    1,769
    Likes Received:
    798
    First Language:
    Spanish
    Primarily Uses:
    RMVXA
    ...........b....but.... that's the point of the text_size() o_O to return the required rect for a clear display, relative to the window size.

    I don't know what you're trying to fix then..... THAT is how you calculate the text width for a given string.
    if you need to adjust it, start from the requirement, compare with your window size, and adjust the difference.
    like I said, it's an interface problem, not a drawing problem: the text will adjust to the rect you give it... if it doesn't fit, it'll shrink, and if it doesn't fit because you're changing the interface, then you need to account for that difference when you pass down the rectangle to draw the text in.
    (The game always leaves an extra pixel or two around the edges, for safety reasons. Maybe you're going below that margin despite the block appearing "just right", and that's why it shrinks... give it an extra pixel when you pass it down, instead of modifying the actual drawing.)
     
  8. Sixth

    Sixth Veteran Veteran

    Messages:
    2,130
    Likes Received:
    798
    First Language:
    Hungarian
    Primarily Uses:
    RMVXA
    @gstv87
    Using text_size is only required if you need to position the text in a specific way according to it's text size, and is only useful if that said text is dynamic and will change during the game. In any other instances it would be a giant waste of performance. No buts and ifs here, using it in other cases is simply bad code design (not counting debug and other during-development-phase test cases, but those shouldn't be in the finished product anyway).
    From what I see on that image Valentine90 posted, he doesn't need to use that method, it's a simple batch of texts displayed with left alignment.

    And I finally managed to test this thing...
    [​IMG]
    There really is something wrong here.
    The lower window can clearly take at least 2 more zeros, yet if I add another one, text compression kicks in, just like on the window above it.
    Both windows got the same size and same font properties.
    The red background is the drawable area on the windows, and the same rect I gave to the draw_text method.
    The text_size method returns 276 for the width for the top text (which got +1 zero), and that is the same width as the drawing width used for the text.
    The bottom text got 265 width according to text_size. Clearly, it's calculating something wrong, because the real size is actually 243, give or take 1 or 2 if we count an extra pixel on the left/right sides.

    So, yeah, I have to agree with Valentine90, something is wrong with the text compression calculation.
    I probably haven't noticed this yet, because in all cases I used the default draw_text method, I had plenty of space left for my texts, so the compression couldn't kick in even with false calculation.
     
  9. gstv87

    gstv87 Veteran Veteran

    Messages:
    1,769
    Likes Received:
    798
    First Language:
    Spanish
    Primarily Uses:
    RMVXA
    exactly!
    because the string exceeds the rect *specified* for it.
    if you would draw a rect based on the rect returned by text_size() for the same string, the text should fit, because it's tailored to the text itself.

    this problem only happens when you *specify* a rect rather than *inheriting* it from somewhere else.
    that's why I say to pass down an extra pixel or two from the rect returned by text_size().
     
  10. Sixth

    Sixth Veteran Veteran

    Messages:
    2,130
    Likes Received:
    798
    First Language:
    Hungarian
    Primarily Uses:
    RMVXA
    Did you even read what I wrote? Did you check the image? Do you see the red part? Will the text exceed that if I add another zero?
    Open the image in paint or in any other image editing program and kindly measure the width of that text. The text_size method itself returns false values, which in turn will kick in the text compression flag sooner than it should happen.
    You are saying that we should base our text positions on a faulty method. I can't be the only one here who sees the many wrongs in that...
     
  11. gstv87

    gstv87 Veteran Veteran

    Messages:
    1,769
    Likes Received:
    798
    First Language:
    Spanish
    Primarily Uses:
    RMVXA
    I just checked with both RGD and Game.exe, and text_size() returns the same value! (360, for my test)

    I went on a more deeper truth-seeking trip that would be too wild to post here, so I'll try to sum it up:
    the problem wasn't any of the points we were discussing.... text_size() returns true values, and draw_text() draws what it's supposed to draw.
    the problem comes, within RGD's draw_text()'s *check for maximum width*, which can't be found anywhere, and the only similar thing I could find was MV's equivalent, which then took me to W3's Javascript library
    https://www.w3schools.com/tags/canvas_measuretext.asp
    where I could only work with a simple script.

    the facts are:
    -RGD and Game.exe both return the same value for the same given string.
    -when given a specific string ("0"), Game.exe, with a font type of Arial 24, draws a character 17px wide.
    -17px correlates to the W3's script's output size, so:
    -the *font* Arial 24, correlates between Game and RGD, *so*:
    -draw_text(), requiring an internal width check as specified by Ace's manual and sustained in MV's conversion, and using the same font in both RGD and Game, with the result being different in RGD, results that... !:
    -RGD's draw_text()'s *internal check for width*, is faulty.

    SO:
    you still won't quite solve it by adding extra width to the rectangle before passing it down, it has to be fixed internally.
    it's not the language, it's not the font, it's not the size.... it's the method itself.
     
  12. Robert-Character Creator

    Robert-Character Creator Waiting for Replies Veteran

    Messages:
    483
    Likes Received:
    208
    Location:
    California, USA
    First Language:
    English
    Primarily Uses:
    RMVXA
    Hi! When I use your file, my project crashes when starting or loading a game. Would it be possible to add compatibility to my project, if I sent you a copy? Thanks in advance. :)
     
  13. invwindy

    invwindy Ice Fairy Veteran

    Messages:
    64
    Likes Received:
    58
    First Language:
    Chinese
    Primarily Uses:
    RMVXA
    I am working on a project these days. I will try to fix the resolution bug later.
    For the text drawing problem, @fux2 may have good ideas.
     
  14. invwindy

    invwindy Ice Fairy Veteran

    Messages:
    64
    Likes Received:
    58
    First Language:
    Chinese
    Primarily Uses:
    RMVXA
    If it is possible, please send me a minimum example of crashing. Thank you!
     
  15. miniet

    miniet Warper Member

    Messages:
    4
    Likes Received:
    1
    I found "ace-mode-7-ace" was the problem which is for using 3d like airship.
    after deleting above script, saving script call "SceneManager.call(Scene_Save)" is working fine.
    but script call "DataManager.save_game(0)" delete 1th save slot and doesn't save it actually.
     
  16. Robert-Character Creator

    Robert-Character Creator Waiting for Replies Veteran

    Messages:
    483
    Likes Received:
    208
    Location:
    California, USA
    First Language:
    English
    Primarily Uses:
    RMVXA
    I'm not sure what changed, but everything's working now. Thank you so much anyway for your offer!
     
  17. ZirconStorms

    ZirconStorms VX & VX Ace Scripts Veteran

    Messages:
    323
    Likes Received:
    105
    First Language:
    English
    Primarily Uses:
    RMVXA
    Windows 8.1, working with the lighting demo here.
    Using the Play Movie event command, a .wav version of the files appears in the same folder.
    upload_2019-4-5_8-3-38.png
    You will need to close the game and delete the wav ver. of the file before it can properly play again.
    Playing the video again (either right after, or after having closed the game and reopened it) will cause an error to pop up.
    upload_2019-4-5_8-7-49.png
    Force-closing the game will cause the window to crash afterwards. Not sure what's causing that.
    Video render settings are:
    upload_2019-4-5_8-6-22.png

    Edit:
    Window borders still change after you exit out of ALT+Enter fullscreen
    Before:
    upload_2019-4-6_15-10-55.png
    After:
    upload_2019-4-6_15-10-39.png
     

    Attached Files:

    Last edited: Apr 7, 2019
  18. Valentine90

    Valentine90 Veteran Veteran

    Messages:
    36
    Likes Received:
    12
    Location:
    Brazil
    First Language:
    Português
    Primarily Uses:
    RMVXA
    I have tested the Mouse.scroll function, but it is not working completely. If I roll the middle mouse button up, it returns 120, but if I roll the middle button down, it does not return anything.
     
  19. JakenBear

    JakenBear Villager Member

    Messages:
    9
    Likes Received:
    1
    First Language:
    English
    Does anyone have a good way to get an Xbox 360 controller working with RGD? Ever since version switching from RGDV1.2.1 to the latest version, our Xbox 360 controller does not work. Is there additional code or script I need to add to RGDv1.3.2 to ensure the controller support works as before. Any help would be appreciated. Thanks.
     
  20. Knighteriius

    Knighteriius The Apple Veteran

    Messages:
    551
    Likes Received:
    197
    Location:
    Underneath the Apple Tree
    First Language:
    English
    Primarily Uses:
    RMVXA
    Hey @JakenBear I needed help with this a month or two ago and so I contacted my favourite bunny of the forums and he helped me out. @Sixth hope you don't mind me sharing the script you wrote up so the controller works in RGD?
    Code:
    =begin
    
    - XInput Patch v1.1
    - Made by: Sixth
    - Requires: RGD
    
    This is just a small patch to integrate RGD's XInput controller checks for all
    input checks in your project without the need to add in the new controller
    checks for every single input check in every script of yours.
    
    I don't recommend using this script if you are planning to use all of the
    buttons from the XBOX controller, because, by default, only 8 buttons are
    supported, but an XBOX controller (and most other controllers too nowadays) has
    more.
    
    It will only check for one controller input, the first one it detects.
    Well, at least it should, but since I don't own an XBOX controller, I can't
    really check if it works as intended or not.
    
    Aside from the added XInput checks for your XBOX controller, the default input
    checks are still working, so the keyboard checks and the default controller
    checks will still operate as they did before adding this patch.
    
    You can put this script anywhere on your script list.
    
    =end
    
    module XInput
    
      # Format:
      #
      #   :default_symbol => [:controller_symbol_1, :controller_symbol_2, ...],
      #
      # Don't change the default symbols!
      # You can change which controller button(s) will be assigned to the default
      # input checks by changing the controller symbols on the right side in the
      # arrays. The controllor symbols must be in an array!
      # All included controller buttons for a default symbol will do the same when
      # they are pressed.
      # Refer to the RGD documentation for the available controller symbols.
      #
      # You can add in custom symbols as default symbols too, but they won't do
      # anything until you actually check for that symbol in your input checks,
      # which the default scripts don't do, so I didn't include any here.
      Keys = {
       :DOWN  => [:DPAD_DOWN],   # DOWN
       :UP    => [:DPAD_UP],     # UP
       :LEFT  => [:DPAD_LEFT],   # LEFT
       :RIGHT => [:DPAD_RIGHT],  # RIGHT
       :A     => [:X],   # Dash key
       :B     => [:B],   # Cancel key
       :C     => [:A],   # Confirm key
       :L     => [:LEFT_SHOULDER, :LEFT_THUMB],    # Page Up
       :R     => [:RIGHT_SHOULDER, :RIGHT_THUMB],  # Page Down
       :X     => [:START],   # Not used by default - custom scripts may use it
       :Y     => [:Y],       # Not used by default - custom scripts may use it
       :Z     => [:BACK],    # Not used by default - custom scripts may use it
      }
    
    end
    
    # End of settings! Don't mess with the code below! Or do... I don't care. :P
    
    class << Input
    
      attr_accessor :pref_ax, :dir4, :dir8
    
      @pref_ax = ''
      @dir4 = @dir8 = 0
    
      alias add_xinput9927 trigger?
      def trigger?(arg)
       return add_xinput9927(arg) || xinput_check("trigger?",arg)
      end
    
      alias add_xinput7724 press?
      def press?(arg)
       return add_xinput7724(arg) || xinput_check("press?",arg)
      end
    
      alias add_xinput1773 repeat?
      def repeat?(arg)
       return add_xinput1773(arg) || xinput_check("repeat?",arg)
      end
    
      def xinput_check(mtd,arg)
       control = Input::Controller.first_state || Input::Controller.states[0]
       return false unless XInput::Keys[arg]
       return XInput::Keys[arg].any? {|sym| control.send(mtd,sym) }
      end
    
      def update_dir
       xx = get_x
       yy = get_y
       @dir8 = num_dir(xx,yy)
       if xx != 0 && yy != 0
         if @pref_ax == 'x'
           yy = 0
         else
           xx = 0
         end
       elsif xx != 0
         @pref_ax = 'y'
       elsif yy != 0
         @pref_ax = 'x'
       end
       @dir4 = num_dir(xx,yy)
      end
    
      def get_x
       xx = 0
       xx -= 1 if press?(:LEFT)
       xx += 1 if press?(:RIGHT)
       return xx
      end
    
      def get_y
       yy = 0
       yy -= 1 if press?(:UP)
       yy += 1 if press?(:DOWN)
       return yy
      end
    
      def num_dir(x,y)
       if x != 0 || y != 0
         return 5 - y * 3 + x
       else
         return 0
       end
      end
      
      alias fix_dirs7761 update
      def update
       fix_dirs7761
       update_dir
      end
    
    end
    # END OF SCRIPT! O_O
    
    Just chuck this in, this makes the controller work and the player walk with the d-pad, not with the analogue. Sixth would have to do some extra handling to make it work for the analogue and as they are a busy bunny I'm not sure if they would be inclined to do that.

    EDIT: Fixed code after a smiley fiasco for not putting it in code inserts.
     
    Last edited: May 14, 2019
    BCj likes this.

Share This Page