Re: The Evolution of a Programmer (humor)

That was what I needed - it works
But why B8000000?
If memory serves me, when you do the same in basic or assembly, it is just b800?

I think I know the answer to that - doing it in assembly you have an address and a segment. This combines it into one

Next question - is it possible to set the video mode from turboc? I have a feeling that might be more difficult

Note that the address is different depending on the mode... and yes, these are Segment:Offset values, so depending on your compiler you'll need to learn how to express them. MAKE_FP is one common macro to achieve it.

HEY I actually got it working - set the video mode, and plotting individual pxels!

Great! I remember well the day I managed to do that ... It's been a long time, keep going!

If anyone is interested in where I am going with this -
I set it for the 320x200 256-color mode
First goal is to set a scrolling starfield
But first to set a random pattern
Then I realized this isn't a text screen - 320 x 200 is a lot at the individual pixel level
So I wrote a function that take a byte and breaks it down into bits and sets those on the screen - so I can set 8 at once
There may be a better way to do it - will keep playing with it

VGA graphic memory starts at A0000, and in mode 13h (320*200, with 256 colours) the memory is linear and every byte defines a point. No need to pack/unpack bytes (unless you use X modes).

ncmark wrote on 2024-06-22, 16:12:

First goal is to set a scrolling starfield

a worthy goal 😀 i start all my twitch streams with a demo i made of starfield, copper bars, and two scrollers.

ncmark wrote on 2024-06-22, 16:12:

If anyone is interested in where I am going with this - I set it for the 320x200 256-color mode First goal is to set a scrolling […]
Show full quote

If anyone is interested in where I am going with this -
I set it for the 320x200 256-color mode
First goal is to set a scrolling starfield
But first to set a random pattern
Then I realized this isn't a text screen - 320 x 200 is a lot at the individual pixel level
So I wrote a function that take a byte and breaks it down into bits and sets those on the screen - so I can set 8 at once
There may be a better way to do it - will keep playing with it

Obviously a demoscener is born here - so your path leads you there!

https://www.pouet.net/

Well - I wanted to create an initial star-field
But it had to look somewhat random - ruling out a simple loop
Finally did it with an array of locations
Next step is to get a simple scroll routine going
I have a feeling I am not going to get away without having some kind of off-screen buffer

a starfield normally requires a vector since your doing 3d on 2d as distance, assuming its the normal starfield of stars coming toward the screen. unless you just mean horizontal scrolling starfield, then you dont really need vectors.

Graphics programming during this period often relied on patching and conservative updates of screen portions to be able to run fast enough on slow machines. That's why earlier scrollers were quite an achievement (e.g. Keen 1) as they ran on XTs yet were able to do smooth scrolling in all directions.

So... Like mpeg before mpeg?

If anyone is interested....
I got the screen scroll going - nothing fancy, just scrolling the screen
But is is SLOW - was expecting it to be faster
I SUSPECT - I could speed it up my creating a buffer in RAM and copying it once rather than reading writing video RAM
I'm going to have do do that anyway - if I am going to have to have a ship on top a scrolling field, that scrolling field will have to be stored in RAM somewhere
but - for now - I am happy it works

the problem is - I got spoiled to programming on the c64 - with the sprite graphics, all I had to do was point it to a memory location and tell it where to be - and that could exist on top of anything else.
This is MUCH more complicated

ncmark wrote on 2024-06-24, 01:08:

I SUSPECT - I could speed it up my creating a buffer in RAM and copying it once rather than reading writing video RAM

You definitely want to avoid reading video ram. Obviously writing it is unavoidable... but for scrolling you can use the same trick keen uses: change the starting offset and only draw the part of the image that gets scrolled "in".

Exactly, scroll using hardware registers. Full-screen modification should be done with writes only, and even that will move you to require 386 if you do it every frame.

myne wrote on 2024-06-23, 13:36:

So... Like mpeg before mpeg?

Hehe.. not quite. It's typically referred to as "dirty rectangle tracking". If you know a certain area on the screen is changing (e.g. a sprite is moving, or changing looks).. you just redraw that specific area and keep everything else intact. With careful timing, you can schedule such updates past the beam trace and thus achieve smooth and fast animation without back buffers. Many games did this back in the days.