Jump to content

Asmusr

Members
  • Content Count

    4,000
  • Joined

  • Last visited

  • Days Won

    13

Posts posted by Asmusr


  1. Just played through it on a real machine. It's an absolutely playable demo with a few puzzles, and not too hard. A few glitches with the blood stains. The red potions give health and and green potions and the barrels give might (the ability to attack). You need to use the mouse or joystick to get and use the keys. I wish a had a TIPI so I could try the mouse interface, but it's supposed to work well.

    • Like 2

  2. 35 minutes ago, apersson850 said:

    I'm sure refactoring your code could save you a thousand bytes. If you want to add more features.

    Refactoring assembly code can be almost as difficult as writing it in the first instance. It helps to have good tools, but AFAIK GDMike is working retro style.


  3. On 2/3/2021 at 5:14 PM, GDMike said:

    I've got to build a 1 way Street. Because Ive got 3200 bytes left and I've still got to build a LOAD routine and other stuff...

    Is that because your program is running from 8K cartridge space? Since you're using SAMS anyway there must be other options.

     

    • Like 1

  4. 6 hours ago, pnr said:

    If one is looking for simple & fast mathematical functions, consider using lookup tables. The original Forth needed that (it was created for software controlling telescopes); if I remember well the arithmetic was done using scaled 32 bit integers, with the each function looked up in a 64 entry table and using interpolation.

    I have used lookup table for sin and cos lots of times, my raycaster being a good example. They are nice functions to look up because they are periodic and symmetric and different only by phase. A lookup takes only a couple of instructions whereas calling the TIPI of F18A would take a lot longer.

    I remember I got an FPU for my 386DX BITD when I became interested in ray tracing. It did speed up things quite a lot, but it could still take hours to render a screen.

     


  5. 1 hour ago, artrag said:

    Maybe using multiple images for different scales could help to render sprites with better aliasing.

    You could use 2 or 3 intermediate images and scale the actual size from the closest scale 

    Yes maybe hand drawn images at lower resolutions would do better at keeping important details than the basic sampling algorithm I'm using, but it's not something I'm going to investigate because I'm quite happy with how it's working now. The thing to remember when you draw textures is that small details are fine as long as they are not important. If you draw something that people need to see it has to be quite big.

    • Like 1

  6. 2 hours ago, Elia Spallanzani fdt said:

    If the monster position is near to the door, when the player enter the room must rotate to see the monster, so the monster in that time can get nearer.

     

    For the stepping back, 

    a man normally retreats slower than he advances.

    This could justify the limitation.

     

    P.s. please consider that i know little english.

    If we wanted to achieve that you only see monsters when they are close and big there are several ways to do that, but I don't think that's desirable. On the contrary, the scaling of the textures at different sizes is a major feature of this game engine that's quite unique on the TI.

    • Like 3

  7. 3 hours ago, Elia Spallanzani fdt said:

    Ok. if raphael also showed the result at a lower resolution, the creator of the icon could try to optimize.

    I'm not sure if a view that, for instance, dropped every second pixel would be that helpful.

    4 hours ago, Elia Spallanzani fdt said:

    - establish that monsters preferably move along walls;

    I'm not sure how that would help?

    4 hours ago, Elia Spallanzani fdt said:

    - prohibit the player from stepping back, or making the move slower.

    Don't you think that would be slightly annoying? And how would you approach the monsters in the first instance?

     

    I don't think this is an issue that needs a solution. It's just something to be aware of when you draw textures.

    • Like 2

  8. 9 hours ago, Elia Spallanzani fdt said:

    wait, are you saying your game can't show these images?

    No that's not what I'm saying. At close range you should see most of the pixels since the screen resolution of 128x64 is a good match for the texture resolution of 32x64. But when you move further away the quality deteriorates rapidly as I have tried to illustrate with these images. It's a bigger issue for the enemies, which you usually don't want very close to you, than for the walls.

     

    apelich.png.5553188c6cc4ba8f5d44cc0d08f077b7.pngapelich2.png.49bfa8d08437fde0077f684e75637d28.pngapelich3.png.932267be183276f7349a14415ce80f6a.png

    • Like 1

  9. 8 hours ago, GDMike said:

    Aha. I just treat like any other VSBW.

    I did it. I think.

    My code for manipulating byte 9 of the PAB.

    LI R0, My pab address

    LI R1,>15 or what value I need it to be

    BLWP @VSBW

     

    Well I'm used to writing character values in VDP not moving other values. So I kept thinking I was placing a character value.

    Anyway, that did write my sub folder new filename.

     

    The file length should be in the most significant byte of R1 before the call to VSBW. If you use LI R1,>15 it will be in the least significant byte, so you have to swap the bytes first:

     

    LI R0,PABADR+9

    LI R1,>15

    SWPB R1

    BLWP @VSBW

     

    In the real program you won't use LI because the length will not be known until runtime, so you will need a MOV to get the length into R1.

     

     

    • Thanks 1

  10. On 1/23/2021 at 12:39 PM, Elia Spallanzani fdt said:

    Monsters and objects are drawn with raphael?

    Yes, but I use a 32x64 resolution now, with 2x1 pixels. And any sprites, i.e. monsters and objects that are not 'walls', should have a transparent background (color 0).


  11. On 11/6/2019 at 7:55 PM, Asmusr said:

    The ultimate sound expansion should be backwards compatible but provide value to existing software just by plugging it in, in the same way as the F18A does. Maybe one could choose between different default sounds/wave forms (the default-default being good old square waves) and different effects (reverb, fake stereo, etc.)? Then it should allow developers to produce better sound that falls back nicely to the standard PSG by having registers for choosing wave forms for each channel, registers for stereo effects, panning, echo, etc. And finally it should include new features, e.g. more channels, sound synthesis, etc. You could use the new features to enrich the sound in a way that would still fall back nicely to the standard PSG, or you could break compatibility and add different 'sound drivers' to your games. 

    SID Master is great, but so far I haven't had the drive to support it in my games. For the hardware guys out there, if you're looking for a project, I'm repeating my idea for a new, backwards compatible, sound chip/card.

    • Like 6
×
×
  • Create New...