Jump to content
  • Advertisement


  • Content Count

  • Joined

  • Last visited

Community Reputation

6 Neutral

About bzt

  • Rank

Personal Information

  • Interests

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. bzt

    Strange Assembly Error

    @Steve_Segreto: you are totally right, now that I know it's for W3D it makes a lot more sense. Also DOSBOX is the best chance for running that, I agree. However "push ebp" is not a valid 16 bit instruction, and mixing "push ebp" and a real-mode BIOS "int 10h" in the same function is clearly a mistake, and it won't work. @yaboiryan: don't use that engine imho. Back then it was hard to make a 3Dish game, so there are lot of tricks and quirks in the code tied strongly with the running environment and the hardware to make it happen. Use an engine that separates execution environment and game logic more clearly (like Duke Nukem 3D for example, or Quake 1). I'd also suggest to switch to a more sophisticated OS than DOS+DPMI, which takes the heavy burden off your shoulders, like Linux for example. But if you insists, there's already a great and easy map editor for W3D (http://www.wolfenstein3d.co.uk/utilities.htm), suprisingly it's called MAPEDIT.EXE and runs in DOSBOX too. Cheers, bzt
  2. Hi, This only matters for the CPU. GPU doesn't simply care, because both structured buffers can be set up as a VertexAttribute so that the shader couldn't tell the difference. Now setting up VertexAttributes could utilize differently structured VBOs, read this https://www.khronos.org/opengl/wiki/Vertex_Specification_Best_Practices Finally, if we interpret "I am wondering if merging two buffers into one single buffer is better ?" as merging two VBOs into a single VBO, then the answer is definitely yes. Switching from a VBO to another and setting up a new VertexAttribute structure for it is a very expensive process. It's always faster not doing anything, because you already have the appropriate data bounded to the shader :-) Cheers, bzt
  3. bzt

    Strange Assembly Error

    Hi, I seriously doubt this could ever work. First, your assembly is for real mode. Just because you changed the header to "32 bit OS", doesn't make the code valid in protected mode, hence the syntax errors most likely. Second, even if you fix the syntax errors, that code is calling real mode BIOS functions, which are not and never were available in protected mode. Third, if you have a new machine, chances are good there's no BIOS at all, as it's using UEFI. Unless you configure a legacy CSM, then even if you switch the CPU mode back to real mode you couldn't use those interrupts. Fourth, if you could fix everything I've listed so far, even then that assembly code is using VGA IO registers directly, something that modern video cards won't like or respect. Chances are good that this code would simply crash unless you have an old VGA-compatible video card. To help you understand the situation: real mode: 16 bit operation mode of the CPU, which allows accessing 64K of memory at once, and 1M tops with segmentation. protected mode: 32 bit operation mode of the CPU, which allows access to 4G of memory, and provides memory protecion (hence the name). The CPU's internal operation is fundamentally incompatible with real mode (different stack alignment, existence of interrupt descriptor table, existence of privilege levels etc. etc. etc.) BIOS: a program stored in a ROM which was compiled for real mode. It provides so called interrupt services, like int 0x10 and int 0x16 you try to use. UEFI: successor to BIOS, which does not provide any real mode services of any kind. New machines have only this, and maybe, if you're lucky, they have a special CSM module installed, which provides a legacy compatibility mode for BIOS. IO registers: special address space in the CPU, independent to the memory, in which all peripherals has an address (or more addresses) and which is accessible regardless to the CPU mode. A certain video card standard, the Video Graphics Array used the port 0x3C8. Other newer standards, like SVGA, XGA or XWGA however does not. Some cards emulated the VGA modes and IO ports to retain compatibility, but that's long gone by now. Modern cards doesn't even support "teletype output mode" any more, which you try to set with SetTextMode_near, only linear frame buffers. Cheers, bzt
  4. Hi, Don't overcomplicate your shader when there's no need. When you call VkVertexInputAttributeDescription, specify VK_FORMAT_B8G8R8A8_UINT, and in your shader simply use vec4. The 32 bit color codes will be converted automatically and transparently into 4 floats for the shader input. Cheers, bzt
  5. Thank you all for your responses! @Green_Baron: It was a long time ago when I worked with GL, did not know linear algebra functions were removed, good to know! I think that your second code is the answer. @DerTroll: thank you for the yutsumura link, that's what I was looking for! I was thinking about something like Solution 1, but yeah, Solution 2 (same as Green Baron's answer) is way better. It's so trivial, that I haven't even considered it... My bad! @Zakwayda: thanks for this clear and simple description of the solution! Cheers, bzt
  6. Hi guys, I've an OpenGL question, which is quite math ad linear algebra related. Let's assume we have two coordinate systems, S (scene) and O (object). I'd like to place O inside S, so I need O' (in S coordinates). Using the following transformation matrices I can do that: rotation, scale, displacement. So far so good. I have two questions though: 1) assuming the place of O' is specified with 4 points (zerus, and one for each axii unit vector end points) how can I calculate the required transformation matrices? It's a "simple" case, as let's say points are P0, P1, P2, P3 and x = P0->P1, y = P0->P2, z = P0->P3. Also |x| = |y| = |z| (all has the same length) and they enclose 90 degree with each other. This surely can be solved using standard GL transformations easily, I just need an algorithm to calculate the matrices from P0, P1, P2, P3. 2) the more difficult question, how can I do the same if O' can be distorted, so |x| != |y| != |z| and their angle is not necessarily 90 degree? (Imagine that you "sit" on O, so O' became stretched and it's top became larger and moved to the side, so that angle(x, y) = 80 degree for example). How to get the required transformation matrices in this universal case, when you only know P0, P1, P2, P3? Hope it's clear what I'm asking. I need an algorithm to generate a transformation matrix that I can then use to transform all points in O into O'. bzt
  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!