The Newprog discussion thread

[Stefan Bauwens]

I decided to make this thread so that I might know who, if there are any people, know the language.
Then we could talk and hopefully help each other with our problems.

Also if someone knows the creator of Newprog, or a working way to contact him, please share.(Since I've been looking for him )

If anyone's already interested, my current problem is that when I use the scroll commands, it shifts in monochrome and not the greyscale.

[DJ Omnimaga]

Hmm I never used the language but maybe someone could invite him here or something. It could be a bug since the language didn't have many updates (although I think it's supposed to be finished). Not a lot of people used it since 68K almost completely died since 2006.

[Eiyeron]

I know someone that used that language, but not for long

[DJ Omnimaga]

If I remember, it was kinda like Axe Parser in style, but unlike Axe Parser, it required an extra launcher to run programs. In Axe you could choose any shell you want or none at all. The language had huge potential, though. I guess the 89 not being as popular anymore just never allowed it to take off like Axe did. (Actually back then the 83+ community was really quiet too, but not as bad as the 68K)

[Stefan Bauwens]

Great news(for me, at least ).
I solved my problem, by looking  bit at an example program include with newprog.
For people who are interested are have the same problem I'll explain it here.
I was doing:

Code: [Select]

if up()
light()
bscroll(100)
dark()
bscroll(100)
...
endif
if right()
light()
lscroll(160)
dark()
lscroll(160)
...
endif
Instead of using 160 when scrolling horizontally, I should have used 100 as well. This also used to cause some crashes, so it's good to know.
Also, I was using savescr(),loadscr() and clrlcd() when drawing from my map(after I had shifted the screen). I took this away, and just changed the drawing mode when doing so.

Code: [Select]

Gmode(gor)
^Use when shifting the screen

Code: [Select]

Gmode(greface)
^Use when drawing new tiles.

So, if you have the same problem, this should have fixed it.

[TIfanx1999]

Just out of curiosity, can you utilize the full screen space with Newprog? That was always something that bothered me about TI-89 BASIC.

[Stefan Bauwens]

You mean, use the whole, whole screen? Ofcourse you can! You can eventually look at a screenie of Pop 89 or any other newprog program on Ticalc.org to see it.
Edit:
I tried my program on tiemu and on vti and both show a blank screen upon running. Does anyone know why. Could greyscale be a problem?(It works fine on my real ti-89)
Edit2:Mvm, I forgot to send some other vars to tiemu. xD

[TIfanx1999]

Ahh, that's good then. ^^

[Stefan Bauwens]

Okay, I have a question. It's more of a general question that I believe non-newprog users can answer and I didn't want to make a new topic just for it.
Is it okay to use pixeltest(gpix in my case) for collision detection? I always try to avoid pixeltests as much as I can since I get "Crappy programmer"-feelings with it.
I am using smoothscrolling and my x gets added/subtracted by one by every 16 pixels I move.
When I jump up and move to the right(for example) and try to jump on a block I fall trough it since I moved less than 16 pixels so my current collision detection check for a block before the block I'm trying to jump on, and since on that spot there is no I fall trough.
It's a bit complicated to explain, but people who used collision detection before hopefully understand.

Thanks in advance.

[TIfanx1999]

I don't know about newprog, but IIRC in 83+ BASIC pixel test is the fastest(or one of the fastest) ways to do collision detection.

[Stefan Bauwens]

Okay, thanks. I think Newprog's gpix() is pretty fast so I'll use that.

[DJ Omnimaga]

Does the language has severe memory limitations like MLC had on the 86 btw? In that language you could only use one array/list, for example, so if you were making an RPG you could only have one map (with possibly 8-9 rooms in it) and the entire game couldn't be more than 8 KB in size.

[Lionel Debroux]

AFAICT, nope.

[chickendude]

For collision detection, assuming all of your tiles are square and there aren't any irregular shapes in the collision area of your tiles, what i generally do is something like this. If you are going up, add the y velocity to the current y position and check what tile is in that new y position. If it is passable, save the new y position. If it isn't passable, you need to save (old y position % F8h): essentially, remove the y offset so that it is aligned to the tile. When checking collisions below you, you'll need to add 2 (if your coordinates are stored in multiples of 8) or 16 (if they're stored in pixels) to the y position before checking, since you need to check the position below the player. If it isn't passable, then just remove the y offset from the new coordinates and store that. If you're only going to be moving 1 pixel at a time, it can be simplified a little since you won't need to worry about aligning the player to the next tile (they will already be aligned). You can also limit your checks to every 16 pixels, but i like to do it every frame since it makes it easier for example to test if you are standing in lava and need to do damage to the player, etc.

*Edit AOC* in order to prevent 8) from turning into a smiley emoticon, check the "Don't use smileys" box when posting.

[Stefan Bauwens]

Thanks Chickendude, but it looks like gpix(pixeltest) will do the trick as well for now. I'll see later perhaps if I implement physics and checks.